Fast Basic v4.x-Beta: Crash / Lock...

[Faicuai]

OK, here's one that got me off-line for quite a bit, but I expect should be solved easily... (could not find a separate thread specifically for this purpose, though...)

 

Mind you that this one causes a complete lock-up of the machine (probably stuck at infinity loop). After quite a good deal of "gymnastics", I managed to narrow it down to this:

 

10 zI=1: S=100-xI  (then CTRL-R)

 

Yes, it looks like nothing... but it dies. It seems that an "in-line" (after ":") algebraic declaration involving a non-declared variable is the main offender.

 

WORKAROUND: you will need to split the statement after ":" in two separate lines, the parser catches the error successfully, and stops. If not... boom...

Edited August 12, 2019 by Faicuai

[_The Doctor__]

ah never mind...

you are trying to see what happens on errors...

and found nirvana  :)

Edited August 12, 2019 by _The Doctor__

[Faicuai]

34 minutes ago, _The Doctor__ said:

ah never mind...

you are trying to see what happens on errors...

and found nirvana 

Remember the Strings thread?

 

I was working on revised version of Banana-sort, which ended up being much more complex than I thought... and I started working on Fast-Basic because it is MUCH easier and way faster o handle the code there... and made that little mistake... which took me quite a while to catch... plus having FB crashed upon compiling...

 

That's where it comes from... ?

Edited August 12, 2019 by Faicuai

[Kyle22]

A typo should NEVER be able to make the computer go into an endless loop.

 

[Faicuai]

3 minutes ago, Kyle22 said:

A typo should NEVER be able to make the computer go into an endless loop.

 

Correct!

 

Although it is tricky, I admit... it took me quite a while to figure out the offending line, and the actual error's mechanics.

 

But we are in Beta stage, so these things will only appear when digging deeper, and I am sure it will be corrected easily.

 

FastBasic is a FANTASTIC piece of work, and a permanent tool in my retro-arsenal, already! ?

Edited August 13, 2019 by Faicuai

[dmsc]

Hi!

On 8/12/2019 at 11:02 PM, Faicuai said:

Correct!

 

Although it is tricky, I admit... it took me quite a while to figure out the offending line, and the actual error's mechanics.

 

But we are in Beta stage, so these things will only appear when digging deeper, and I am sure it will be corrected easily.

 

FastBasic is a FANTASTIC piece of work, and a permanent tool in my retro-arsenal, already! ?

Thanks, and thank you foro the bug report.

 

The problem was that the parser was not consuming the ':' between statements on errors, so it kept trying to parse the line over and over.

 

Bug fixed and test case added, current BETA version attached - source is on github as always: https://github.com/dmsc/fastbasic

 

Please, try this version as I could not test this parser change a lot.

 

Have Fun!

 

fastbasic.atr

[Faicuai]

11 hours ago, dmsc said:

Hi!

Thanks, and thank you foro the bug report.

 

The problem was that the parser was not consuming the ':' between statements on errors, so it kept trying to parse the line over and over.

 

Bug fixed and test case added, current BETA version attached - source is on github as always: https://github.com/dmsc/fastbasic

 

Please, try this version as I could not test this parser change a lot.

 

Have Fun!

 

fastbasic.atr 130.02 kB · 8 downloads

It works sweet, indeed!

 

Now that we are focusing on the Parser, I am throwing at it all wrenches I can think of... If I find anything unusual, I will report it on this thread.

 

Cheers and keep up the F-AMAZING work!!!

[Faicuai]

Just wondering (if anyone knows):

 

Where is the latest-beta repository of FastBasic?

 

I remember downloading recently a version for correcting a 450+ editor-lines bug, but it was buried in some comments...  

 

Working REALLY WELL, so far!!!

 

???

Edited September 13, 2019 by Faicuai

[+mytek]

https://github.com/dmsc/fastbasic

 

[Faicuai]

32 minutes ago, mytek said:

https://github.com/dmsc/fastbasic

 

THANKS, but I probably did not explain myself, clearly enough...

 

I have already checked that site... What I am looking for is the repository with Betas derived from most recent commits... Unless I am missing something (which is quite possible), I could not find it anywhere in there...

[+mytek]

4 hours ago, Faicuai said:

THANKS, but I probably did not explain myself, clearly enough...

 

I have already checked that site... What I am looking for is the repository with Betas derived from most recent commits... Unless I am missing something (which is quite possible), I could not find it anywhere in there...

No my mistake, I should have realized you could just as easily find the link I posted via the same method I used -- Google.

 

Good luck with your quest, hopefully someone chimes in with what you are seeking .

 

[Preppie]

I'm not exactly sure what you're asking for but dmsc sent me this after he fixed the most recent bug I found (the memory issue after the 450 editor bug).

fastbasic.zip

[Mclaneinc]

On 8/12/2019 at 10:59 PM, Faicuai said:

OK, here's one that got me off-line for quite a bit, but I expect should be solved easily... (could not find a separate thread specifically for this purpose, though...)

 

Mind you that this one causes a complete lock-up of the machine (probably stuck at infinity loop). After quite a good deal of "gymnastics", I managed to narrow it down to this:

 

10 zI=1: S=100-xI  (then CTRL-R)

 

Yes, it looks like nothing... but it dies. It seems that an "in-line" (after ":") algebraic declaration involving a non-declared variable is the main offender.

 

WORKAROUND: you will need to split the statement after ":" in two separate lines, the parser catches the error successfully, and stops. If not... boom...

Sir, you live to break stuff...You are a madman

 

Seriously, its the beta testers dream, find the thing that makes it fail..Damn annoying when it all works

 

That blooming Avery and all his working code

[dmsc]

Hi!

14 hours ago, Faicuai said:

THANKS, but I probably did not explain myself, clearly enough...

 

I have already checked that site... What I am looking for is the repository with Betas derived from most recent commits... Unless I am missing something (which is quite possible), I could not find it anywhere in there...

 

Sorry, I don't usually publish the compiled betas, because I want to avoid the proliferation of distinct versions. I should make a release soon, but I had a of of work lately and I want to add a few thinks before the release.

 

But the last source is always at github, where you can also read the changes at https://github.com/dmsc/fastbasic/commits/master . I have fixed a few bugs and made the IDE smaller, now the integer IDE is at 7943 bytes, but I want to use that space to add more stuff.

 

If you want to test current development version, this is the ATR attached.

 

Have Fun!

fastbasic.atr

[Faicuai]

1 hour ago, dmsc said:

Hi!

 

Sorry, I don't usually publish the compiled betas, because I want to avoid the proliferation of distinct versions. I should make a release soon, but I had a of of work lately and I want to add a few thinks before the release.

 

But the last source is always at github, where you can also read the changes at https://github.com/dmsc/fastbasic/commits/master . I have fixed a few bugs and made the IDE smaller, now the integer IDE is at 7943 bytes, but I want to use that space to add more stuff.

 

If you want to test current development version, this is the ATR attached.

 

Have Fun!

fastbasic.atr 130.02 kB · 3 downloads

EXCELLENT!!!

 

BTW, I read all commits. so far, and it is clear you have been working around the clock on it.... AWES0ME work, there!

 

FYI, Ran across a benchmark (part of research work in the UK) that requires two-dimensional arrays... I can perfectly simulate them with linear arrays, but I wondered if there are any plans (or code-space) left for handling these?

 

Anyways, a big thanks!!

Edited September 14, 2019 by Faicuai

[dmsc]

Hi!

22 minutes ago, Faicuai said:

EXCELLENT!!!

 

BTW, I read all commits. so far, and it is clear you have been working around the clock on it.... AWES0ME work, there!

Thanks!

22 minutes ago, Faicuai said:

FYI, Ran across a benchmark (part of research work in the UK) that requires two-dimensional arrays... I can perfectly simulate them with linear arrays, but I wondered if there are any plans (or code-space) left for handling these?

 

No, I don't plan to implement two-dimensional arrays, as I think that for the intended use of FastBasic (simple games and programs) it is not really necessary, and would complicate the parser.

 

What I do want to add is:

 

- DLIs: I have a test build that allows having one DLI, but I want to be able to define multiple DLIs. Problem is, you need to manually alter the display list to activate the DLI points, I think this is messy. Currently, this is 93 bytes.

- Support for BREAK key in the IDE. I have a working implementation that does not slows down the programs, but it would only work in the XL OS, this is 43 bytes.

- A way to include sources/binaries in the program, to allow the IDE to compile larger programs.

- Finish the full cross compiler. I have a working test version, but a lot of optimizations are needed.

 

Any other ideas for game-related development?

 

Have Fun!

[FifthPlayer]

The DLI support sounds interesting.  Does FastBasic offer a way for a programmer to provide an assembly-language DLI handler(s)?  Or does FastBasic include its own built-in DLI handler that provides a specific set of services (like changing color registers, or player-missile position registers)?

 

Edited September 15, 2019 by FifthPlayer

[dmsc]

Hi!

10 hours ago, FifthPlayer said:

The DLI support sounds interesting.  Does FastBasic offer a way for a programmer to provide an assembly-language DLI handler(s)?  Or does FastBasic include its own built-in DLI handler that provides a specific set of services (like changing color registers, or player-missile position registers)?

 

Current code looks like:

' DLI sample
'-----------

' Setup Display List:
POKE DPEEK(560)+10,130

' Setup and activate DLI
DLI [ POKE $D01A,$34 : POKE $D018,$80 ]

GET K	' Waits for key press

' Setup and activate new DLI, old DLI is cleared automatically
DLI [ POKE $D01A,PEEK(20) : POKE $D018,$C4 ]

GET K	' Waits for key press

' Clear DLI
DLI

 

But, in the DLI handler you can only do POKE and PEEK of constant memory locations, no variables or other functions/statements are allowed.

 

Have Fun!

[Faicuai]

21 hours ago, dmsc said:

Hi!

Thanks!

 

No, I don't plan to implement two-dimensional arrays, as I think that for the intended use of FastBasic (simple games and programs) it is not really necessary, and would complicate the parser.

 

What I do want to add is:

 

- DLIs: I have a test build that allows having one DLI, but I want to be able to define multiple DLIs. Problem is, you need to manually alter the display list to activate the DLI points, I think this is messy. Currently, this is 93 bytes.

- Support for BREAK key in the IDE. I have a working implementation that does not slows down the programs, but it would only work in the XL OS, this is 43 bytes.

- A way to include sources/binaries in the program, to allow the IDE to compile larger programs.

- Finish the full cross compiler. I have a working test version, but a lot of optimizations are needed.

 

Any other ideas for game-related development?

 

Have Fun!

 

I don't have that many game-related suggestions, but these are the ones that I've always had in mind (may very well serve for gaming purposes);

 

1. First and foremost, the ability to load "extensions" package to FastBasic core (e.g. "FBX" command, or so). This could be engineered from the perspective of loading FB's core in RAM, or to keeping its footprint <= 8192 bytes, so it loads between $A000 and $BFFF as a ROM cart. Note that bytes from $BFFA to $BFFF may not be used for code.
2. Ability to alternate between FastBasic and ASSEMBLY, in a fully in-line manner, without every having to leave your Basic listing, and with easy and full access to existing declared variables. That would be a F-HOME RUN (!). Extensions above maybe needed for this.
3. Ability to declare BYTE-length (8bits) integer variables. Something like "dim I byte", for instance.
4. Ability to handle 8bits or 16bits integer variables, declared with SINGLE-LETTER names (e.g. A,B,C, I, J, etc.) that would not require any special look-up code in FB interpreter / compiler, and would exist in fixed, pre-set memory locations (up to one page or RAM, 128 variables?)
5. Ability to change 709 & 710 color locations. Currently implementation does not really respect the presence of already-set values on these registers, such as SDX's global "SCRDEF" variable, which I extensively use. Also, this would help tremendously when editing in emulated 80-cols. mode, as using OS's 709/710 default values render rather poor contrast and edge-definition when working on this particular mode (80col).
6. DO NOT worry about incorporating Fast-E routines on existing FB code. We can address than really well outside of it, via DOS extensions, or even at OS level (I already have a fully functional, fully-featured XE_03 OS load that also incorporates a fast and reliable E: accelerator, blowing every singly benchmark that I have thrown at it).

 

My 0.02c to make Atari's overall fastest Basic on the planet even better!

 

Cheers!

Edited September 15, 2019 by Faicuai

[dmsc]

Hi!

21 hours ago, Faicuai said:

I don't have that many game-related suggestions, but these are the ones that I've always had in mind (may very well serve for gaming purposes);

 

1. First and foremost, the ability to load "extensions" package to FastBasic core (e.g. "FBX" command, or so). This could be engineered from the perspective of loading FB's core in RAM, or to keeping its footprint <= 8192 bytes, so it loads between $A000 and $BFFF as a ROM cart. Note that bytes from $BFFA to $BFFF may not be used for code.

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.

 

21 hours ago, Faicuai said:

1. Ability to alternate between FastBasic and ASSEMBLY, in a fully in-line manner, without every having to leave your Basic listing, and with easy and full access to existing declared variables. That would be a F-HOME RUN (!). Extensions above maybe needed for this.

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.

 

21 hours ago, Faicuai said:

1. Ability to declare BYTE-length (8bits) integer variables. Something like "dim I byte", for instance.

I don't think that would be useful, as all the arithmetic would be in 16bit, so the speed would be exactly the same.

 

21 hours ago, Faicuai said:

1. Ability to handle 8bits or 16bits integer variables, declared with SINGLE-LETTER names (e.g. A,B,C, I, J, etc.) that would not require any special look-up code in FB interpreter / compiler, and would exist in fixed, pre-set memory locations (up to one page or RAM, 128 variables?)

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.

 

21 hours ago, Faicuai said:

1. Ability to change 709 & 710 color locations. Currently implementation does not really respect the presence of already-set values on these registers, such as SDX's global "SCRDEF" variable, which I extensively use. Also, this would help tremendously when editing in emulated 80-cols. mode, as using OS's 709/710 default values render rather poor contrast and edge-definition when working on this particular mode (80col).

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.

 

21 hours ago, Faicuai said:

1. DO NOT worry about incorporating Fast-E routines on existing FB code. We can address than really well outside of it, via DOS extensions, or even at OS level (I already have a fully functional, fully-featured XE_03 OS load that also incorporates a fast and reliable E: accelerator, blowing every singly benchmark that I have thrown at it).

 

My 0.02c to make Atari's overall fastest Basic on the planet even better!

 

Cheers!

 

Have Fun!

 

[baktra]

A question to dmsc.

Where would you prefer to have these kinds of posts? In the FastBasic thread of the 8bit/5200 development thread, or here in the wild?

 

[dmsc]

Hi!

27 minutes ago, baktra said:

A question to dmsc.

Where would you prefer to have these kinds of posts? In the FastBasic thread of the 8bit/5200 development thread, or here in the wild?

 

 

The FastBasic thread in the development forum is better, as I read it often and it is kept all in one place.

 

Have Fun!

 

 

 

[FifthPlayer]

On 9/15/2019 at 7:40 AM, dmsc said:

Hi!

 

Current code looks like:

' DLI sample
'-----------

' Setup Display List:
POKE DPEEK(560)+10,130

' Setup and activate DLI
DLI [ POKE $D01A,$34 : POKE $D018,$80 ]

GET K	' Waits for key press

' Setup and activate new DLI, old DLI is cleared automatically
DLI [ POKE $D01A,PEEK(20) : POKE $D018,$C4 ]

GET K	' Waits for key press

' Clear DLI
DLI

 

But, in the DLI handler you can only do POKE and PEEK of constant memory locations, no variables or other functions/statements are allowed.

  

Have Fun!

 

This looks really nice.  It's a nice happy medium between the two scenarios I proposed.  Most of the time a DLI just stuffs hardware registers anyway.

 

I guess with this code you have to provide your own bespoke display list.  I don't see any syntax for specifying at what scanline the DLI should be triggered.

 

As far as supporting multiple DLIs, is your problem with syntax or is it having FastBasic do the work of managing the display list?  Because if you require the programmer supply the display list up front, the syntax problem seems solvable.   If you give each DLI its own number/ID, and perhaps require the programmer to declare the number of DLIs up front, you can then allow devs to update DLIs dynamically.

 

 

[dmsc]

Hi!

1 hour ago, FifthPlayer said:

This looks really nice.  It's a nice happy medium between the two scenarios I proposed.  Most of the time a DLI just stuffs hardware registers anyway.

 

I guess with this code you have to provide your own bespoke display list.  I don't see any syntax for specifying at what scanline the DLI should be triggered.

Yes, it's in the line above:

POKE DPEEK(560)+10,130

 

1 hour ago, FifthPlayer said:

As far as supporting multiple DLIs, is your problem with syntax or is it having FastBasic do the work of managing the display list?  Because if you require the programmer supply the display list up front, the syntax problem seems solvable.   If you give each DLI its own number/ID, and perhaps require the programmer to declare the number of DLIs up front, you can then allow devs to update DLIs dynamically.

 

The problem is synchronizing the DLI to the display position. There are two ways:

- On DLI start, check the current ANTIC line and dispatch to the code. Problem with this is that you add code to each DLI, makes difficult to comply with the timing requirements.

- At each DLI change VDSLST to point to the next DLI address. This is faster and simpler, but you must synchronize with the start of display or your DLIs could jump around. Best way is with a VBI, this makes FastBasic code mucho more complicated.

 

Do think on any other way to manage this?

 

Have Fun!

 

[FifthPlayer]

2 hours ago, dmsc said:

Do think on any other way to manage this?

 

Have Fun!

 

 

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.

 

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.

 

Edit: now that I think about it, a mutex wouldn't be necessary as long as any updates to the chain of DLIs occur before the first user DLI is invoked.  So perhaps the FastBasic DLI synchronizer interrupt could also do any necessary work to update the DLI chain, after it has set the vector to the first DLI.

Edited September 16, 2019 by FifthPlayer
more thought about DLI updates