Aquileo | Recent changes to wiki

Aquileo | The strange strings of uBasic modified by thebeez

2025-12-19T16:21:45.084000Z

--- v35
+++ v36
@@ -106,6 +106,6 @@

 All in all, apart from some lookup tables, *not a single line* in the original uBasic/4tH source was changed. The code was simply added to the existing code and could be removed with the same surgical precision. Which is *exactly* what happened when we revised the *entire* GC. Just examine the source if you want to verify. You'll see.

-In the meanwhile, the uBasic/4tH strings can *no longer* be considered "immutable". The point is, although it is quite possible to construct a subroutine that composes a string from two halves and a new character, it quickly leads to fragmentation of the heap. All you need is a medium loop. 
+In the meanwhile, the uBasic/4tH strings can *no longer* be considered "immutable". The point is, although it is quite possible to construct a subroutine that composes a string from two halves and a new character, it quickly leads to fragmentation of the heap. All you need is a medium sized loop. 

 Here, **PEEK()** proved to be an inspiration, since it clips the range  of characters that can be accessed - and reduces that range to the actual elements of the array - no matter what. By limiting access to named string variables only - and thus excluding transient strings - risks could be further eliminated. And hence, **POKE** was born.

Aquileo | The strange strings of uBasic modified by thebeez

2025-12-19T16:21:08.879000Z

--- v34
+++ v35
@@ -106,4 +106,6 @@

 All in all, apart from some lookup tables, *not a single line* in the original uBasic/4tH source was changed. The code was simply added to the existing code and could be removed with the same surgical precision. Which is *exactly* what happened when we revised the *entire* GC. Just examine the source if you want to verify. You'll see.

-In the meanwhile, the uBasic/4tH strings can *no longer* be considered "immutable". The point is, although it is quite possible to construct a subroutine that composes a string from two halves and a new character, it quickly leads to fragmentation of the heap. Here, **PEEK()** proved to be an inspiration, since it clips the range  of characters that can be accessed - and reduces that range to the actual elements of the array - no matter what. By limiting access to named string variables only - and thus excluding transient strings - risks could be further eliminated. And hence, **POKE** was born.
+In the meanwhile, the uBasic/4tH strings can *no longer* be considered "immutable". The point is, although it is quite possible to construct a subroutine that composes a string from two halves and a new character, it quickly leads to fragmentation of the heap. All you need is a medium loop. 
+
+Here, **PEEK()** proved to be an inspiration, since it clips the range  of characters that can be accessed - and reduces that range to the actual elements of the array - no matter what. By limiting access to named string variables only - and thus excluding transient strings - risks could be further eliminated. And hence, **POKE** was born.

Aquileo | The strange strings of uBasic modified by thebeez

2025-12-19T16:19:51.329000Z

--- v33
+++ v34
@@ -106,4 +106,4 @@

 All in all, apart from some lookup tables, *not a single line* in the original uBasic/4tH source was changed. The code was simply added to the existing code and could be removed with the same surgical precision. Which is *exactly* what happened when we revised the *entire* GC. Just examine the source if you want to verify. You'll see.

-In the meanwhile, the uBasic/4tH strings can *no longer* be considered "immutable". The point is, although it is quite possible to construct a subroutine that composes a string from two halves and a new character, it quickly leads to fragmentation of the heap. Here, **PEEK()** proved to be an inspiration, since it clips the range  of characters that can be accessed - and reduces it to the actual characters of the string - no matter what. By limiting access to named string variables only - and thus excluding transient strings - risks could be further eliminated. And hence, **POKE** was born.
+In the meanwhile, the uBasic/4tH strings can *no longer* be considered "immutable". The point is, although it is quite possible to construct a subroutine that composes a string from two halves and a new character, it quickly leads to fragmentation of the heap. Here, **PEEK()** proved to be an inspiration, since it clips the range  of characters that can be accessed - and reduces that range to the actual elements of the array - no matter what. By limiting access to named string variables only - and thus excluding transient strings - risks could be further eliminated. And hence, **POKE** was born.

Aquileo | The strange strings of uBasic modified by thebeez

2025-12-19T16:18:03.374000Z

--- v32
+++ v33
@@ -104,6 +104,6 @@

 That having said, the philosopy is *so different* from ordinary BASIC interpreters and compilers that some programs are just not well suited for a straight conversion. I did the classic "Hangman", which heavily depends on manipulating a character matrix. That required almost a full rewrite since uBasic/4tH really doesn't allow efficient manipulation of individual characters - "immutable strings", remember? Others, like the classic "Animal", worked just fine, since you can assign strings to array elements. 

-In the meanwhile, the uBasic/4tH strings can no longer be considered "immutable". The point is, although it is quite possible to construct a subroutine that composes a string from two halves and a new character, it quickly leads to fragmentation of the heap. Here, **PEEK()** proved to be an inspiration, since it clips the range characters that can be accessed to the actual size of the string. By limiting the access to string variables only - and thus excluding transient strings - risks could be significantly reduced. Furthermore, by closely guarding the current boundaries of the string, the remaining risks could be fully eliminated. And hence, **POKE** was added.
+All in all, apart from some lookup tables, *not a single line* in the original uBasic/4tH source was changed. The code was simply added to the existing code and could be removed with the same surgical precision. Which is *exactly* what happened when we revised the *entire* GC. Just examine the source if you want to verify. You'll see.

-All in all, apart from some lookup tables, *not a single line* in the original uBasic/4tH source was changed. The code was simply added to the existing code and could be removed with the same surgical precision. Which is *exactly* what happened when we revised the *entire* GC. Just examine the source if you want to verify. You'll see.
+In the meanwhile, the uBasic/4tH strings can *no longer* be considered "immutable". The point is, although it is quite possible to construct a subroutine that composes a string from two halves and a new character, it quickly leads to fragmentation of the heap. Here, **PEEK()** proved to be an inspiration, since it clips the range  of characters that can be accessed - and reduces it to the actual characters of the string - no matter what. By limiting access to named string variables only - and thus excluding transient strings - risks could be further eliminated. And hence, **POKE** was born.

Aquileo | The strange strings of uBasic modified by thebeez

2025-12-19T16:07:54.785000Z

--- v31
+++ v32
@@ -104,6 +104,6 @@

 That having said, the philosopy is *so different* from ordinary BASIC interpreters and compilers that some programs are just not well suited for a straight conversion. I did the classic "Hangman", which heavily depends on manipulating a character matrix. That required almost a full rewrite since uBasic/4tH really doesn't allow efficient manipulation of individual characters - "immutable strings", remember? Others, like the classic "Animal", worked just fine, since you can assign strings to array elements. 

-In the meanwhile, the uBasic/4tH strings can no longer be considered "immutable". The point is, although it is quite possible to construct a subroutine that composes a string from two halves and a new character, it quickly leads to fragmentation of the heap. Here, **PEEK()** proved to be an inspiration, since it clips the range of characters that can be accessed. By limiting access to string variables - and thus excluding transient strings - risks could be significantly reduced. Furthermore, by strict checking the boundaries of the string, the remaining risks could be eliminated. And hence, **POKE** was added.
+In the meanwhile, the uBasic/4tH strings can no longer be considered "immutable". The point is, although it is quite possible to construct a subroutine that composes a string from two halves and a new character, it quickly leads to fragmentation of the heap. Here, **PEEK()** proved to be an inspiration, since it clips the range characters that can be accessed to the actual size of the string. By limiting the access to string variables only - and thus excluding transient strings - risks could be significantly reduced. Furthermore, by closely guarding the current boundaries of the string, the remaining risks could be fully eliminated. And hence, **POKE** was added.

 All in all, apart from some lookup tables, *not a single line* in the original uBasic/4tH source was changed. The code was simply added to the existing code and could be removed with the same surgical precision. Which is *exactly* what happened when we revised the *entire* GC. Just examine the source if you want to verify. You'll see.

Aquileo | The strange strings of uBasic modified by thebeez

2025-12-16T15:49:44.528000Z

--- v30
+++ v31
@@ -102,7 +102,7 @@
 ~~~
 And that is completely OK, because *strings are  immutable*, remember? I've created a few uBasic programs using this system and it turned out to be pretty transparent. As a user of uBasic/4tH you don't have to bother with everything that happens in the background and in practice  errors are caught pretty well - which is quite of handy since you're bound to make 'em.

-That having said, the philosopy is *so different* from ordinary BASIC interpreters and compilers that some programs are just not well suited for a straight conversion. I did the classic "Hangman", which heavily depends on manipulating a character matrix. That required almost a full rewrite since uBasic/4tH really doesn't allow efficient manipulation of individual characters - "immutable strings", remember? Others, like the classic "Animal", worked just fine, since you can assign strings to array elements. In short, when converting existing programs your mileage may vary.
+That having said, the philosopy is *so different* from ordinary BASIC interpreters and compilers that some programs are just not well suited for a straight conversion. I did the classic "Hangman", which heavily depends on manipulating a character matrix. That required almost a full rewrite since uBasic/4tH really doesn't allow efficient manipulation of individual characters - "immutable strings", remember? Others, like the classic "Animal", worked just fine, since you can assign strings to array elements. 

 In the meanwhile, the uBasic/4tH strings can no longer be considered "immutable". The point is, although it is quite possible to construct a subroutine that composes a string from two halves and a new character, it quickly leads to fragmentation of the heap. Here, **PEEK()** proved to be an inspiration, since it clips the range of characters that can be accessed. By limiting access to string variables - and thus excluding transient strings - risks could be significantly reduced. Furthermore, by strict checking the boundaries of the string, the remaining risks could be eliminated. And hence, **POKE** was added.

Aquileo | The strange strings of uBasic modified by thebeez

2025-12-16T15:48:42.084000Z

--- v29
+++ v30
@@ -102,6 +102,8 @@
 ~~~
 And that is completely OK, because *strings are  immutable*, remember? I've created a few uBasic programs using this system and it turned out to be pretty transparent. As a user of uBasic/4tH you don't have to bother with everything that happens in the background and in practice  errors are caught pretty well - which is quite of handy since you're bound to make 'em.

-That having said, the philosopy is *so different* from ordinary BASIC interpreters and compilers that some programs are just not well suited for a straight conversion. I did the classic "Hangman", which heavily depends on manipulating a character matrix. That required almost a full rewrite since uBasic/4tH really doesn't allow efficient manipulation of individual characters - "immutable strings", remember? If that is what your program requires, reconsider. Others, like the classic "Animal", worked just fine, since you can assign strings to array elements. In short, when converting existing programs your mileage may vary.
+That having said, the philosopy is *so different* from ordinary BASIC interpreters and compilers that some programs are just not well suited for a straight conversion. I did the classic "Hangman", which heavily depends on manipulating a character matrix. That required almost a full rewrite since uBasic/4tH really doesn't allow efficient manipulation of individual characters - "immutable strings", remember? Others, like the classic "Animal", worked just fine, since you can assign strings to array elements. In short, when converting existing programs your mileage may vary.
+
+In the meanwhile, the uBasic/4tH strings can no longer be considered "immutable". The point is, although it is quite possible to construct a subroutine that composes a string from two halves and a new character, it quickly leads to fragmentation of the heap. Here, **PEEK()** proved to be an inspiration, since it clips the range of characters that can be accessed. By limiting access to string variables - and thus excluding transient strings - risks could be significantly reduced. Furthermore, by strict checking the boundaries of the string, the remaining risks could be eliminated. And hence, **POKE** was added.

 All in all, apart from some lookup tables, *not a single line* in the original uBasic/4tH source was changed. The code was simply added to the existing code and could be removed with the same surgical precision. Which is *exactly* what happened when we revised the *entire* GC. Just examine the source if you want to verify. You'll see.

Aquileo | Fixed point arithmetic modified by thebeez

2023-03-08T16:31:32.593000Z

--- v9
+++ v10
@@ -43,6 +43,7 @@
 Applications
 ----
 The first time these functions were applied in real life applications was when we tried to recreate an old ZX Spectrum 3D graph. Our first attempt was using Zen float, which - although successful - wasn’t particularly fast. And that was the point we dusted off Brodies fixed point library and started experimenting.
+
 It was fast. Where Zen float took* seconds*, this one finished in the blink of an eye - without any noticeable effects on the final result. That was the point we started to take it serious.

 And that made me wonder. What if I take this a step further and try a much slower environment, like [uBasic/4tH](https://sourceforge.net/p/forth-4th/wiki/uBasic%20and%20Tiny%20BASIC/)? That one has no floating point support whatsoever. So I re-implemented the entire library in uBasic/4tH and started rewriting.

Aquileo | uBasic and Tiny BASIC modified by thebeez

2023-01-09T17:03:23.251000Z

--- v10
+++ v11
@@ -7,11 +7,13 @@
 - `PUSH`, `POP()` and `TOS()` can be used to emulate `DATA` statements, pass parameters to subroutines or make recursive subroutines;
 - `DO`, `LOOP`, `UNTIL`, `WHILE`, `CONTINUE` and `BREAK` supported;
 - Multi line `IF`..`THEN`..`ELSE`..`ENDIF` supported;
-- Parameter passing supported by `GOSUB`, `RETURN` and `FUNC()` extensions;
+- Parameter passing supported by `GOSUB`, `RETURN`, `TRY()` and `FUNC()` extensions;
 - Local variables supported, both initialized and uninitialized, using `PARAM()` and `LOCAL()`;
 - Alphanumeric labels supported;
 - "Structured Basic" commenting style;
 - Simple file I/O support, using `OPEN()`, `CLOSE`, `READ()` and `WRITE`;
+- Input parsing, using `TOK()` and `SKIP`;
+- Exception handling, using `TRY()` and `RAISE`;
 - String support, including familiar functions like `LEN()`, `VAL()`, `STR()` and `JOIN()`.

 Architecture

Aquileo | uBasic and Tiny BASIC modified by thebeez

2022-03-30T12:49:12.968000Z