Subject: Forth

From: Jeffrey White <[email-masked]>
Date: Tue, 5 Apr 2011 21:46:49 -0700 (PDT)

For a microprocessor without a stack, there sure sure a lot of Forth's for the 
99/4A and emulators:

1. TI Forth
2. Wycove Forth
3. Forth P-box card
4. fig-Forth cartridge
5. v9t9 Forth
6. TurboForth
7. X4th99
...(not to mention those than work on the Geneve)

Maybe when I am retired on a beach somewhere gumming my ramen noodles (the diet 
of the college student returns -- cat food is too darn expensive because it must 
meet some minimal nutritional value), drinking a fifth, and running the 99/4A 
emulator of the implanted Apple iCortex pico de gallo 4D+ polyphony gender 
neutered (er, neutral) manufactured and implanted in the Mexican province Tejas 
(Would you like frijoles with that?), I will be able to sort these out.

How about a bubble sort in Forth?  How would you do that?  How do arrays work?  
If they work, do I get "arrays"?  A cup of Juan Valdez?

Word.

Byte $#! twice!

That hurts 60 times a second.  (50 times in Europe.)

Jeff White

p.s.:  After the Miracle Whips (guh-shaw) defeated the Mayo-ists, the 
eggalitarian populace has been forced to emote to the far right.  This has 
caused an incredible increase in global warming, earth quakes, and milk shakes.  
(^:  Soy shakes were anticipated, but we got tit for tat.

---

From: mark wills <[email-masked]>
Date: Wed, 6 Apr 2011 09:33:01 +0100 (BST)

Jeff,

Stay off the caffeine for a day mate! It'll do you good!

Forth has no concept of arrays, but it's trivial to make them yourself:

CREATE MY-ARRAY 100 ALLOT

There you go. A word called MY-ARRAY. MY-ARRAY is actually an executable word. 
When you execute it, it returns the address of the start of the ALLOTed memory. 
You can then use @ (fetch) and ! (store) to read/write items into the array.

:-)

> ------------------------------------
> 
> Yahoo! Groups  Links
> 
> 
> 
>

---

From: fdos <[email-masked]>
Date: Wed, 06 Apr 2011 08:18:53 -0700

Yes, arrays in Forth are trivial.  I even implemented virtual arrays in 
Forth+ 2.0 (not completed), and would have included them in X4th99 where 
512 1K BLOCK BUFFERS are possible, but they are not practical for TF 
because the BLOCK BUFFERS reside in limited VDP memory.

Bill S

-- 
Bill R Sullivan (FDOS)
Go Forth+ or X4th99

---

From: Jeffrey White <[email-masked]>
Date: Wed, 6 Apr 2011 19:46:11 -0700 (PDT)

Mark,

Actually, I typically drink caffeine-free soda, water, juice, or good beer.  
Only at lunch might I have a caffeinated drink, and that was over 12 hours prior 
to the message.  I had had some beer.

Really, why so many Forth's?  TI provided us TI Forth with source code.  Lutz 
Winkler and others fixed bugs and expanded its capabilities.  Forth is easily 
expandable with new words (which can replace existing words).

In February on Atariage 
(http://www.atariage.com/forums/topic/177969-fig-forth-on-ti99/) they were 
discussing putting the fig-forth cartridge for the 99/4A in a cartridge.  The 
rpk for MESS has been on WHT (figforth.rpk in 
ftp://ftp.whtech.com/emulators/cartridge_images/rpk/cartridges/) for over a 
year.

Why this Forth or that Forth?  How compatible are they?  Much software for the 
TI was written in BASIC or Extended BASIC, and the other BASIC's may be nicer 
and less buggy, but most authors wrote to the defacto TI standards.

I suppose you are at an advantage -- if you can call it that -- that no Forth 
has really taken off.  Other than BASIC, Extended BASIC, assembly, and (to a 
much lesser extent) c99, none of the other languages for the 99/4A caught fire.

Jeff White

p.s.: Why do French-style green beans have no beans?  Should I be boycotting 
them?

________________________________
From: mark wills <[email-masked]>
To: [email-masked]
Sent: Wed, April 6, 2011 4:33:01 AM
Subject: Re: [TI994A] Forth

Jeff,

:-)

> 7. X4th99
<snip>

---

From: fdos <[email-masked]>
Date: Wed, 06 Apr 2011 23:10:48 -0700

Jeff,

I can't speak for Mark and others, but I'm part of the "Forth for all 
applications", and make it more acceptable to TI programmers advocates. 
  Usually this means the majority of TI programmers that mainly rely on 
XB for their efforts.  Only a few graduate to AL programming due to the 
learning difficulty.  I must also say that we have quite a number of XB 
variants also.  Why so many Extended Basics?

In the case of Forth for the TI, up till now all variants are based on 
fig-Forth; TI Forth, Wycove Forth, Super4th and a few other lesser known 
ones.  X4th99 is under development and may be dropped in favor of just 
adding the major benefits of X4th99 to TurboForth.  The reason for 
X4th99 was to take advantage of more memory available with AMS/SAMS, and 
to make it easier for XB programmers to move to Forth.  Lots of familiar 
XB functions have been added.  Most of which come from my MDOS Forth+ 
which is an enhancement to TI Forth for MDOS on 9640 Geneve by Mike 
McCann.  This consisted mainly only of the kernel and none of the electives.

I was forced to use paged memory for the enhanced TI Forth kernel in 
X4th99, so that a minimum of 8K free dictionary space, in conventional 
memory, would be available to the user.  Two 4K library zones are in low 
memory (>2000 ~ >3FFF), and 4K for virtual memory (BLOCK BUFFERS) in 
high memory (>A000 ~ >AFFF).

This brings us to TurboForth which is 16K in Jon Guidry cartridge ROM, 
thus leaving almost 32K of free dictionary space for the user.  Mark has 
optimized his F83 standard Forth for the TI-99/4A architecture, making 
it much faster than Ti Forth, so ideal for furiously fast games.

In order to adapt X4th99 features to TF I will have to convert my 
fig-Forth code to F83 standard, and I can use low memory for the two 
library zones, and BLOAD the MMOS or MMLS into high memory still leaving 
16K ~ 20K for the user (no virtual memory paging due to BLOCK BUFFERS 
being in VDP memory).

My 2 cents worth.

Bill S

On 4/6/2011 7:46 PM, Jeffrey White wrote:
> From: mark wills<[email-masked]>

-- 
Bill R Sullivan (FDOS)
Go Forth+ or X4th99

---

From: mark wills <[email-masked]>
Date: Thu, 7 Apr 2011 09:15:22 +0100 (BST)

<snip>
(no virtual memory paging due to BLOCK BUFFERS being in VDP memory).
</snip>

Should still be possible. You still have BLOCK. It's just that the address 
returned by BLOCK is a VDP address, not a CPU address. You can still get the 
contents of the blocks easily, with V@ and V!

VMBR and VMBW are provided to transfer to/from CPU memory, so I don't see any 
reason why it can't be done. It is a little more convoluted, however, since V@ 
and V! are byte oriented (because VDP is 8 bits wide), thus, it might be a 
little more convenient to define a couple of helper words to provide 16-bit 
based access to VDP:

: VW@ ( vdp_address -- word_value)\ reads a 16-bit word from VDP memory
  DUP V@ 8 << SWAP 1+ V@ OR ; 

: VW! ( word_value vdp_address -- ) \ writes a 16 bit word to VDP memory
  2DUP SWAP 8 >> SWAP V! 1+ V! ;

You now have 16-bit fetch and store words for VDP memory. So they can be used 
just like @ and !

At the programmers 'level' he doesn't care that the data is in VDP.

This *is* very non-standard though. I basically decided to leverage the VDP 
memory in the TI, which is un-used a lot of the time. It seemed silly to keep 
blocks in CPU memory, eating away at available program space, when VDP was lying 
empty...!

Woohoo! 9.00am and I'm doing Forth. It's gonna be a good day!

Mark

----- Original Message ----
> From: fdos <[email-masked]>
> Sent: Thu, 7 April, 2011 7:10:48

---

From: fdos <[email-masked]>
Date: Thu, 07 Apr 2011 09:58:53 -0700

Hi Mark,

First off I can't find where you said how many BLOCK BUFFERS are in VDP. 
  Originally you had 4 in CPU memory.

Let's imagine we have TF with MMLS also paging >A000 ~ >AFFF for virtual 
BLOCK BUFFERS as the two binary code 4K libraries are in low memory at 
 >2000 ~ >3FFF.  Let's also say we set the number of virtual 1K BUFFERS 
to 128 which will use 32 x 4K pages of SAMS, and that we have maybe 67 
BUFFERS already loaded from disk, but now we want to list or edit one of 
those disk BLOCKS, and then we choose BLOCK 371 from file GEEK1.  Which 
means we have to set the current fileblock to GEEK1 with USE.  Now we 
have to find out if that specific BLOCK is already loaded and if so 
which BUFFER it's in, and if found map the 4K page with that BUFFER or 
find that BLOCK in the GEEK1 file.  Next we need to allocate one of the 
VDP BUFFERS to receive the content of BLOCK 371 from the specific 1 of 4 
BUFFERS in the BUFFER page at >A000 or from the disk file.  Transfer the 
contents.  Whew!

Let's say we've updated all 67 BLOCKS in our 1K BUFFERS which now means 
they all have to be saved back out to the correct fileblock and BLOCK 
number.  Normally we would loop through all the BLOCK BUFFERS in memory 
looking for those with update flags set and write them to disk, but now 
we have to determine which diskfile & BLOCK they came from to do it or 
maybe it would be better to loop through each fileblock that we have 
loaded BLOCKS from instead.  We absolutely have to have all updated 
BLOCKS be written to the correct fileblock and BLOCK or we have a very 
big mess on our hands.  Yuck!

We still have to send these updated BLOCKS to VDP BUFFERS, so they have 
to be FLUSHed first, so we can transfer our updated CPU BUFFERS to VDP 
BUFFERS and mark them as updated then FLUSH (provided they are arranged 
by fileblock therefore are saved to the correct fileblock and BLOCK) we 
repeat the process until all the updated BLOCKS in the current fileblock 
are FLUSHed, and then we change to the next fileblock with USE, and do 
the same process again until all fileblocks with updated BLOCKS have 
been FLUSHed.  BTW each fileblock has to be a complete path & filename.

I don't know about you, but I stopped having fun several paragraphs 
back. :-(

Bill S

On 4/7/2011 1:15 AM, mark wills wrote:
>    DUP V@ 8<<  SWAP 1+ V@ OR ;
>
>    2DUP SWAP 8>>  SWAP V! 1+ V! ;
>
>> From: fdos<[email-masked]>
>> memory  (>2000 ~>3FFF), and 4K for virtual memory (BLOCK BUFFERS) in
>> high  memory (>A000 ~>AFFF).
>>

-- 
Bill R Sullivan (FDOS)
Go Forth+ or X4th99