Defining CHARs with binary numbers

[+TheBF]

I have been working on developing TI-BASIC style GRAPHICS for CAMEL99 Forth.

 

My thoughts on the matter are to make these things work similar to TI-BASIC where possible.

For example the color values are the same, 1 through 16, even though the hardware wants 0 to 15.

 

I have replicated the simple things CLEAR, SCREEN, COLOR and even added a new one called COLORS

which changes background and foreground colors for the entire character set in one line.

 

Years ago something that was always a pain was developing graphics shapes for CALL CHAR.

Nowadays I see there is a great editor for the job that outputs BASIC code. Very cool.

 

The CALL CHAR sub-program tries to make it simpler for us by letting us input a hexadecimal string for the

character bits and a decimal number for the ASCII value. In Forth I could switch the radix wtih

HEX and DECIMAL and it would look like this:

 

HEX FFFF FFFF FFFF FFFF DECIMAL 128 CHARDEF

( I had to call it something different because CHAR is already a standard word in ANS Forth so I chose CHARDEF)

 

I didn't like that much so I automated the number conversion from HEX to DECIMAL by adding a word called HEX"

 

HEX" FFFF FFFF FFFF FFFF" 128 CHARDEF

 

That was good enough thought I... but what if I could input the bits as BINARY numbers?

 

So I created BIN"

 

And now with the help of the swap-byte operator '><' and the '+' operator I can do this:

 

BIN" 01111110" >< ( swap this byte to other side: 00FF becomes FF00 )
BIN" 10000001" + ( add this byte to the previous one to create a 16bit number)
BIN" 10100101" ><
BIN" 10000001" +
BIN" 10100101" ><
BIN" 10011001" +
BIN" 10000001" ><
BIN" 01111110" + 128 CHARDEF

 

It's not as nice as a real icon editor but sure is faster for me to code than using HEX numbers.

 

 

BF

 

 

 

 

[+Lee Stewart]

I hesitate to comment on “developing TI-BASIC style GRAPHICS for CAMEL99 Forth” because I think I understand the desire. However, my perspective is from TI Forth and, now, my fbForth, which are based mostly on arguments expected by the TMS9900 Assembler as implemented by the E/A cartridge, especially where TI-99/4A functions/subroutines are invoked—i.e., zero-based arguments for the most part.

 

That said, I very much like your HEX" and BIN" words!

 

...lee

[+TheBF]

I hesitate to comment on “developing TI-BASIC style GRAPHICS for CAMEL99 Forth” because I think I understand the desire. However, my perspective is from TI Forth and, now, my fbForth, which are based mostly on arguments expected by the TMS9900 Assembler as implemented by the E/A cartridge, especially where TI-99/4A functions/subroutines are invoked—i.e., zero-based arguments for the most part.

 

That said, I very much like your HEX" and BIN" words!

 

...lee

 

Thanks Lee,

 

Here are the definitions in ANS Forth. Not fancy as you can see, and they do a hard switch back to decimal.

( HEX" converts a string into HEX numbers and returns to DECIMAL radix)
: HEX"  ( -- <text>)  HEX [CHAR] " PARSE EVALUATE DECIMAL   ;

( BIN" converts a binary number string onto the stack returns to DECIMAL radix)
: BIN"  ( -- <text>)  2 BASE ! [CHAR] " PARSE EVALUATE DECIMAL   ;

Well if it helps I am liberally "borrowing" graphics code from TI-Forth.

 

Found some quick gains in the words that use 4 * and 8 * multiple times in the graphics BLOCKS

Changed them to :

: 4*     ( n -- n.4)  2 LSHIFT ;

: 8*     ( n -- n.  3 LSHIFT ; 

I think these are about 4X faster than using 4 * because of the Forth NEXT linkage and save a few bytes too, being re-used.

 

Part of the reason for the TI-BASIC color scheme is to assist any daring TI-BASIC programmer who might be interested in trying Forth.

Things like control values get locked into your mind after working with a system for awhile, so I feel their (potential) pain.

 

EDIT* I suppose I could add something like "OPTION BASE" that is used in BASIC. Hmmm..

 

BF

Edited April 5, 2017 by TheBF

[Opry99er]

That's pretty neat.

[+Lee Stewart]

Not that you want to go in that direction, but I converted almost all of the TI Forth graphics words to ALC, especially the graphics primitives. The TI Forth versions were abysmally slow.

 

...lee

[+Lee Stewart]

EDIT* I suppose I could add something like "OPTION BASE" that is used in BASIC. Hmmm..

 

Now, there’s a thought!

 

...lee

[Opry99er]

I like OPTION BASE.

[+TheBF]

Not that you want to go in that direction, but I converted almost all of the TI Forth graphics words to ALC, especially the graphics primitives. The TI Forth versions were abysmally slow.

 

...lee

 

I know you mean. I took a look at VCHAR and it was huge!.

I reduced it to this.

: ?EOSCR ( vdpadr -- ) C/SCR @ > ABORT" off screen" ;

: VCHAR  ( x y char cnt -- ) ( parameter order not ideal so we shuffle)
         >R >R               ( -- x y ) ( push char & cnt to rstack)
         >VPOS               ( -- vdpaddr)  ( calc the Video position in memory)
         R> SWAP             ( -- char vadr) ( get the char and reverse order)
         R> 0                ( -- char vadr cnt index) ( all that crap to get this)
         ?DO                 ( -- char vadr) ( let 'er rip)
            2DUP VC!         ( write char to video memory)
            C/L @ +          ( calc.  next row)
            DUP ?EOSCR       ( did we go too far?)
         LOOP
         2DROP ;

Maybe my top of stack cache and few other speed-ups will keep it moving.

But for sure the stack juggling to get parameters in order is painful

 

My actual goal is education on how to cross-compile Forth so I shouldn't be so concerned but...

 

Hi level Forth still performs better than BASIC right?

 

BF

 

*edit* As I look at this I think it can go faster if I use the loop index to calculate the VDP address directly.

Edited April 5, 2017 by TheBF

[Willsy]

 

Here are the definitions in ANS Forth. Not fancy as you can see, and they do a hard switch back to decimal.

( HEX" converts a string into HEX numbers and returns to DECIMAL radix)
: HEX"  ( -- <text>)  HEX [CHAR] " PARSE EVALUATE DECIMAL   ;

( BIN" converts a binary number string onto the stack returns to DECIMAL radix)
: BIN"  ( -- <text>)  2 BASE ! [CHAR] " PARSE EVALUATE DECIMAL   ;

 

Nice!

 

FWIW they look similar in TF (which is ye olde Forth-83

 

 

: HEX"  ( -- <text>)  HEX ASCII " WORD EVALUATE DECIMAL   ;
: BIN"  ( -- <text>)  2 BASE ! ASCII " WORD EVALUATE DECIMAL   ;

[+TheBF]

 

 

Nice!

 

FWIW they look similar in TF (which is ye olde Forth-83

: HEX"  ( -- <text>)  HEX ASCII " WORD EVALUATE DECIMAL   ;
: BIN"  ( -- <text>)  2 BASE ! ASCII " WORD EVALUATE DECIMAL   ;

 

To paraphrase Churchill regarding the US and UK :

 

"We are two programmers separated by a common language"

 

BF

[+TheBF]

To get VCHAR to go faster without writing everything in Assembler I did this to my original version.

This pretty much doubled the speed. Turns our the ?EOSCR test that uses ABORT" was very

slow to put inside a loop.

( created this little word to speed up C/L @ +)

CODE: C/L+   ( n -- n')       
             _C/L @@ TOS ADD,
              NEXT,
              END-CODE

: VCHAR  ( x y char cnt -- ) 
         >R >R               
         >VPOS      
         R> SWAP 
         R> 0        
         ?DO         
            2DUP VC!                     
            C/L+             ( use tiny ASM word inside the loop)
            C/SCR @ MIN      ( *EDIT* clipping the value is faster)
         LOOP
         2DROP ;

[+Lee Stewart]

Hooboy!—While checking the various Basics and Forths for how VCHAR is implemented to compare with CAMEL99 Forth’s version, I discovered inconsistencies and/or errors I was not expecting! Here is a comparison table, with “end of screen” abbreviated “EOS”:

 

Language EOS Result

----------------- -------------------------------------------------------------

TI Basic Continues to EOS, wraps, increments column and fills screen

TI Extended Basic Continues to EOS, wraps, increments column and fills screen

TI Forth Continues to EOS, wraps, increments column and fills screen

fbForth 2.0 Wraps to top and fills column (!?)

TurboForth Continues to EOS, wraps, increments column and fills screen

CAMEL99 Forth Continues to bottom of screen column...then writes to EOS + 1

TI Forth and TurboForth duplicate what TIB and XB do. I was trying to duplicate TI Forth (I think) in fbForth 2.0. Obviously, I did not! I will probably change it in a future build to conform with TIB and XB.

I understand your not wanting to allow VCHAR to wrap—I just wanted to let you know how the others do it. You will have to tell me whether my conclusion about writing the character to EOS + 1 for overflow is correct.

...lee

[am1933]

I'm pretty sure the Bin command was used in ZX Spectrum basic for character definition.

[Opry99er]

100% sure AceForth used it as well. I tried in vain to get an Ace for a long time, then settled on emulation.

 

Love that stupid little machine....

Edited April 9, 2017 by Opry99er

[+TheBF]

Hooboy!—While checking the various Basics and Forths for how VCHAR is implemented to compare with CAMEL99 Forth’s version, I discovered inconsistencies and/or errors I was not expecting! Here is a comparison table, with “end of screen” abbreviated “EOS”:

 

Language EOS Result

----------------- -------------------------------------------------------------

TI Basic Continues to EOS, wraps, increments column and fills screen

TI Extended Basic Continues to EOS, wraps, increments column and fills screen

TI Forth Continues to EOS, wraps, increments column and fills screen

fbForth 2.0 Wraps to top and fills column (!?)

TurboForth Continues to EOS, wraps, increments column and fills screen

CAMEL99 Forth Continues to bottom of screen column...then writes to EOS + 1

TI Forth and TurboForth duplicate what TIB and XB do. I was trying to duplicate TI Forth (I think) in fbForth 2.0. Obviously, I did not! I will probably change it in a future build to conform with TIB and XB.

I understand your not wanting to allow VCHAR to wrap—I just wanted to let you know how the others do it. You will have to tell me whether my conclusion about writing the character to EOS + 1 for overflow is correct.

...lee

 

I had not looked at TI BASIC since 1987 ish.. I forgot that it could do more than 1 vertical column. I have repented of my evil ways.

But it's not a very valuable feature is it? (oops once a heretic...)

 

BF

[+Lee Stewart]

 

I had not looked at TI BASIC since 1987 ish.. I forgot that it could do more than 1 vertical column. I have repented of my evil ways.

But it's not a very valuable feature is it? (oops once a heretic...)

 

BF

 

I would say it is not. That is why (I think—been awhile) I limited it to one column, in spite of what the TI Forth developers did. I now have high-level fbForth words for VCHAR and HCHAR that exactly duplicate TIB and XB versions. The reason I wrote them in high-level Forth is that I like to do that as a model from which to write an ALC version. I then include the Forth version in the comments of any ALC version. I will post them in the fbForth thread later today.

 

...lee

[Tursi]

I used to use it for screen wipes, taking advantage of the wraparound.

[+TheBF]

I used to use it for screen wipes, taking advantage of the wraparound.

Good point. It's an artistic effect.

 

BF