Jump to content

Photo

Camel99 Forth Information goes here

Camel99 Forth Concatentive Programming ANS Forth

190 replies to this topic

#51 TheBF OFFLINE  

TheBF

    Dragonstomper

  • Topic Starter
  • 754 posts
  • Location:The Great White North

Posted Sat Mar 31, 2018 12:15 PM

CAMEL99 Forth 'MORE' utility demonstration video using ANS Forth file words.

 

 

Attached Files



#52 TheBF OFFLINE  

TheBF

    Dragonstomper

  • Topic Starter
  • 754 posts
  • Location:The Great White North

Posted Sun Apr 1, 2018 2:23 PM

Well I am really enjoying having a working file system on Camel99 Forth.   :-D

\ print string left justified
: $.LEFT  ( $ width -- ) 
          OVER C@ - >R COUNT TYPE   R> SPACES ;

DECIMAL
: ?CR     OUT @ 10 + C/L@ > IF CR THEN ;

HEX
: DIR  ( <DSK?.> )   \  needs the '.' ONLY shows file name
          BL PARSE-NAME DUP ?FILE
          RELATIVE 100 FIXED R/O BIN OPEN-FILE ?FILERR
          >R                            \ push handle onto Return stack

          PAD 50 R@ READ-LINE ?FILERR
          CR PAD COUNT TYPE CR

          LINES OFF
          BEGIN
             PAD 50 R@ READ-LINE ?FILERR
          WHILE
             DROP                       \ don't need the byte count
             PAD 0A $.LEFT 2 SPACES ?CR
             ?TERMINAL                  \ check for *BREAK* key
             IF R> CLOSE-FILE           \ if detected we're done here
                2DROP
                CR CR ." *BREAK*" ABORT
             THEN 1 LINES +!
          REPEAT

          R> CLOSE-FILE
          2DROP 2DROP
          DECIMAL
          CR CR LINES @ . ." files"
          HEX ;

Attached Files



#53 TheBF OFFLINE  

TheBF

    Dragonstomper

  • Topic Starter
  • 754 posts
  • Location:The Great White North

Posted Mon Apr 2, 2018 3:36 PM

Version 2.0.5 is On GitHub

 

https://github.com/bfox9900/CAMEL99-V2

 

  • Found some ways to simplify the kernel and remove some names from the dictionary in FILESYSD
  • Fixed a bug in ANSFILES.F that broke "INCLUDE".
  • Uploaded the DIR.F and MORE.F
  • The new STRINGS.F package is pretty fast and let's you do most of what you can do in BASIC.

Todo:

  • Add LOAD and SAVE function
  • Create an editor
  • Make the editor a binary overlay for rapid loading inside the system.

 

Soon I will have to wake up my real iron, repair it and see if this all works in the real world.

 

BF



#54 TheBF OFFLINE  

TheBF

    Dragonstomper

  • Topic Starter
  • 754 posts
  • Location:The Great White North

Posted Sat Apr 7, 2018 12:12 PM

Preliminary CAMEL99 Forth Document Available

 

https://github.com/b...ree/master/DOCS

 

I have created a document to help BASIC programmers understand the things added to Forth for TI BASIC users.

It has a few example programs in the text to let people see how these additions work. I feel like these are the best way to explain things.

 

Let me know if anything doesn't make sense or is broken and I can keep working on it.

 

The system feels pretty stable to me for what it does.  I am sure some real users will find the killer bugs pretty quickly.

 

B


Edited by TheBF, Sat Apr 7, 2018 12:12 PM.


#55 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

  • 3,764 posts
  • Location:Silver Run, Maryland

Posted Sat Apr 7, 2018 6:24 PM

Let me know if anything doesn't make sense or is broken and I can keep working on it.

B

 

Very well-written document!  I have not had a chance at low-level scrutiny (will get there later), but I like what I see.  :)

 

...lee



#56 TheBF OFFLINE  

TheBF

    Dragonstomper

  • Topic Starter
  • 754 posts
  • Location:The Great White North

Posted Sat Apr 7, 2018 8:31 PM

 

Very well-written document!  I have not had a chance at low-level scrutiny (will get there later), but I like what I see.  :)

 

...lee

 

Thanks

 

I have found some errors myself already. :-)  

Appreciate your eagle eyes when you have the time.



#57 TheBF OFFLINE  

TheBF

    Dragonstomper

  • Topic Starter
  • 754 posts
  • Location:The Great White North

Posted Wed Apr 11, 2018 10:28 AM

I am writing and writing... to make something of an instruction manual for CAMEL99.  I started on the Assembler and wrote this for the opening.  I think it is worth sharing.

 

 

Learning Assembly Language the Easy Way

One of the big secrets about Forth is the Forth Assembler. It gives you a way to learn Assembly language in a way that is so much less painful than the traditional Assembler process. You can learn by writing tiny routines that do simple things but very quickly.  You must still understand how the TMS9900 CPU operates and any other system details that your program uses but it follows the “How do you eat an elephant principle?”   Answer:  Piece by piece.

Consider this traditional Assembly language work flow:

1.       Write your program in the editor, save as SOURCE file

2.       Assembler the program with the Assembler, giving OBJECT file.

3.       *Link the OBJECT file with the LINKER giving BINARY file

4.       Load the BINARY file into RAM and watch it CRASH

5.       Goto 1

*TI-99 joins step 3 and 4 with a special “LINKING LOADER” program so they were aware of this issue.

Now consider how you make and Assembler program in Forth”

1.       Start CAMEL99 Forth

2.       Load the Assembler (becomes part of Forth)

3.       Write a short CODE word in Assembly language

4.       Test the CODE word by typing its name

 

A CODE Word Example

Let’s imagine we wanted a way to increment a Forth variable by two at maximum speed.  It turns out that the 9900 CPU can do that in one instruction. Very fast.  Let’s test this idea in the Forth console.

INCLUDE DSK1.TOOLS.F        \ give us the programmer tools

INCLUDE DSK1.ASM9900.F      \ give us the Assembler words

 

\ “two-plus-store” adds 2 to the contents in addr

\ TOS is the CPU register where CAMEL99 caches the “top of stack” value

 

CODE 2+!    ( addr -- )  *TOS  INCT,   NEXT,   ENDCODE

 

\ test it at the Forth console

VARIABLE X

 

X ? 0 ok

X 2+!

X ?  2 ok

X 2+!

X ? 4

 

Seems to work. We are done!

“2+!” is now just another word in the Forth dictionary but it runs really fast.


Edited by TheBF, Wed Apr 11, 2018 10:30 AM.


#58 TheBF OFFLINE  

TheBF

    Dragonstomper

  • Topic Starter
  • 754 posts
  • Location:The Great White North

Posted Fri Apr 13, 2018 7:19 AM

Latest Edition of CAMEL99 Doc is up on GitHub

 

Revision .5 contains a lot more material that lets you get started playing with Forth.

Introduction	8
About CAMEL Forth	8
What you have	9
Library Files	9
File Format	9
Only Needs the E/A Package.	9
File Naming Convention (Optional)	9
Forth Terminology	10
Standard Forth vs CAMEL99 Forth	12
Library files Available with CAMEL99 Forth	12
The Forth Programming Pyramid	13
*Incremental Compiling	13
Loading CAMEL99	14
DSK1.START	14
Lesson 1: Jump Right in	15
Hello World	15
The Colon Compiler	16
Final Thoughts on Hello World	19
Error messages	19
Lesson 2: Transition from BASIC to Forth	20
Structured Programming	21
Moving Closer to Forth Style	21
Trim the Fat	21
Minimal	22
Factoring is the key to good Forth	22
Lesson 3: The DATA Stack	23
What is a computer stack?	23
A Few More Math Examples	25
A Fundamental Difference between BASIC and Forth	25
Why do we use a Stack?	25
EMIT	26
Stack Diagrams	27
Lesson 4: The DO LOOP	28
And one more thing…	30
If you are very curious	30
Strings in Forth	31
CAMEL99 String Word Set	31
Using CAMEL99 String Words	32
Technical Details about STRINGS.F	33
Other Facts	33
Graphics Words	34
A New Word for Convenience	36
COLOR in CAMEL99	37
Memory Tips and Tricks	38
High CPU RAM	38
Low CPU RAM	38
VDP Memory	38
SAMS Memory	38
Fetch and Store for each Space	38
Memory Operators	39
CPU RAM Memory Words	39
VDP Memory Words	39
SAMS Card Memory	39
Stealing Memory Temporarily	41
Temporary Memory Example Program	43
Multi-Tasking	44
Why Multi-Task?	44
Multi-Tasking Commands	44
TASK SWITCHER TECHNICAL EXPLANATION	46
Techie Stuff for the TMS9900 Nerd	47
WARNING for Assembly Language Users	47
CAMEL99 MULTI-TASKING USER AREA	48
Example Multi-tasking Code	49
Assembly Language the Easy Way	50
A CODE Word Example	50
Understanding Our Code Word	51
CAMEL99 Assembler vs TI Assembler	52
Forth Assembler Differences	52
Code Comparison	52
Special Registers in the Forth Machine	53
Proper Use of the TOS Register	53
Structured Branching and Looping	55
Example Programs	56
Random Color Dots	56
Guess the Number in Forth	57
GRAPHICS Example: “Denile”	58
Forth Style Version of Denile	61
Important Idea	61

Many little repairs to demonstration programs.

It never ends but I have other work for today.

 

Happy Friday the 13th :skull:

 

 

 

 

 



#59 TheBF OFFLINE  

TheBF

    Dragonstomper

  • Topic Starter
  • 754 posts
  • Location:The Great White North

Posted Sun Apr 15, 2018 7:38 AM

Between power outages due to the ice storm I have been working to improve the speed of the CAMEL99 V2 kernel but stay within the 8K limit of the cross-compiler.

 

It is fascinating that many times Assembler code takes more bytes to implement a simple routine that Forth.

So the game is truly finding the places that make a difference.

 

One routine that seems to perk up the system is the Forth word HERE which returns the address of the next available memory in the dictionary.

It does nothing but fetch the contents of the dictionary pointer variable called DP.  

Since HERE is used in a lot of places in the kernel, using the extra 2 bytes it takes to code it in Assembler makes a nice improvement.

\ it turns out that by making HERE faster, the system goes faster because HERE is used a lot.
\ : HERE   DP @ ; (Forth version)

CODE: HERE   ( -- addr) 
             TOS PUSH,  
             DP @@ TOS MOV,  
             NEXT, 
             END-CODE

The other routine that I have benchmarked with Turbo Forth is scrolling.  TF uses Assembler and also provides a lot more functionality but in normal scrolling it was much faster.

 

I have finally got a Forth based scroll that uses a 2 line buffer that seems to scroll up at about the same speed as TF. 

The routine takes advantage of the Forth DATA stack to hold values for reading VDP and writing VDP.

This makes it a little cryptic but it works.  

 

By changing the constant C/S you can make the line buffer bigger.

 

In 80 col mode however I find taking 4 lines (360 bytes) a little extreme and performance does not improve much.

So this is now my final scroll.  

[CC] C/L @ 2* [TC] CONSTANT: C/S              \ chars per scroll

: SCROLL      ( -- )
              C/S DUP                         \ get char per scroll and duplicate
              MALLOC ( -- c/s heap)           \ allocate chars per scroll in heap
              C/SCR @  C/L@ VTOP @ +          \ loops from 2nd line, to end of screen
              DO
                 I  ( -- c/s heap scr-addr)
                 OVER 2DUP    C/S VREAD      \ read chars/scroll to heap
                 PAUSE
                 SWAP C/L@ -  C/S VWRITE      \ write HEAP to line above
              C/S +LOOP                       \ advance loop by chars per scroll

              0 17 CLRLN                      \ clear last line
              DROP                            \ drop heap pointer
              MFREE ;                         \ de-allocate heap memory

 Version 2.0.8 will go up on GitHub .... if the power stays up . ;-)


Edited by TheBF, Sun Apr 15, 2018 7:41 AM.


#60 TheBF OFFLINE  

TheBF

    Dragonstomper

  • Topic Starter
  • 754 posts
  • Location:The Great White North

Posted Sun Apr 15, 2018 7:19 PM

I found another couple of words that make a significant difference without taking more space.

 

>DIGIT converts a small number to an ASCII digit.

HOLD puts a digit into memory in a little buffer and maintains a pointer into the buffer going right to left as a number is converted digit by digit.

 

Both of these are part of the hi level command called '#'  which puts both >DIGIT and HOLD inside a loop.

Because they are inside a primary loop making them faster improves performance with every iteration.

 

Here is their Forth code

: >DIGIT ( n -- c) DUP 9 > 7 AND + 30 + ; \ convert n to ascii digit c

\ decr. HOLD pointer HP, Store char at the address contained in HP
: HOLD   ( char -- )  -1 HP +!  HP @  C! ;

And here are their ALC replacements

CODE: HOLD  ( char -- )  \ 2 BYTES bigger, 4X faster
            HP @@   DEC,
            HP @@ W MOV,
            TOS     SWPB,
            TOS  *W MOVB,
            TOS     POP,
            NEXT,
            END-CODE

\ : >DIGIT ( n -- c) DUP 9 > 7 AND + 30 + ; \ convert n to ascii digit c
 CODE: >DIGIT  ( n -- c)   \ ASM is 8 bytes smaller 4X faster
            TOS 9 CMPI,
            @@1 JLE,       \ if n<=9 jump to convert it
            TOS  7 ADDI,   \ else number is not base 10, add 7
 @@1:        TOS 30 ADDI,  \ add 30 to create ASCII value
            NEXT,
            END-CODE

So I save space on these two and number printing measure about 50% faster.

 

The is new code is up on GITHUB now.



#61 TheBF OFFLINE  

TheBF

    Dragonstomper

  • Topic Starter
  • 754 posts
  • Location:The Great White North

Posted Tue Apr 17, 2018 6:55 AM

Between power outages due to the ice storm I have been working to improve the speed of the CAMEL99 V2 kernel but stay within the 8K limit of the cross-compiler.

 

It is fascinating that many times Assembler code takes more bytes to implement a simple routine that Forth.

So the game is truly finding the places that make a difference.

 

One routine that seems to perk up the system is the Forth word HERE which returns the address of the next available memory in the dictionary.

It does nothing but fetch the contents of the dictionary pointer variable called DP.  

Since HERE is used in a lot of places in the kernel, using the extra 2 bytes it takes to code it in Assembler makes a nice improvement.

\ it turns out that by making HERE faster, the system goes faster because HERE is used a lot.
\ : HERE   DP @ ; (Forth version)

CODE: HERE   ( -- addr) 
             TOS PUSH,  
             DP @@ TOS MOV,  
             NEXT, 
             END-CODE

The other routine that I have benchmarked with Turbo Forth is scrolling.  TF uses Assembler and also provides a lot more functionality but in normal scrolling it was much faster.

 

I have finally got a Forth based scroll that uses a 2 line buffer that seems to scroll up at about the same speed as TF. 

The routine takes advantage of the Forth DATA stack to hold values for reading VDP and writing VDP.

This makes it a little cryptic but it works.  

 

By changing the constant C/S you can make the line buffer bigger.

 

In 80 col mode however I find taking 4 lines (360 bytes) a little extreme and performance does not improve much.

So this is now my final scroll.  

[CC] C/L @ 2* [TC] CONSTANT: C/S              \ chars per scroll

: SCROLL      ( -- )
              C/S DUP                         \ get char per scroll and duplicate
              MALLOC ( -- c/s heap)           \ allocate chars per scroll in heap
              C/SCR @  C/L@ VTOP @ +          \ loops from 2nd line, to end of screen
              DO
                 I  ( -- c/s heap scr-addr)
                 OVER 2DUP    C/S VREAD      \ read chars/scroll to heap
                 PAUSE
                 SWAP C/L@ -  C/S VWRITE      \ write HEAP to line above
              C/S +LOOP                       \ advance loop by chars per scroll

              0 17 CLRLN                      \ clear last line
              DROP                            \ drop heap pointer
              MFREE ;                         \ de-allocate heap memory

 Version 2.0.8 will go up on GitHub .... if the power stays up . ;-)

 

 

2 STEPS FORWARD,

1 STEP BACK

DOIN' THE SOFTWARE 2 STEP...

 

I will be publishing version 2.0.9 later today because this little gem had a bug where it killed the top 2 records of my sprite table when it scrolled in GRAPHICS mode.  I tested with my PONG demo program but of course PONG does not scroll.

 

I can't use a constant  that is pre-calculated for all modes. DUH!

 

B



#62 TheBF OFFLINE  

TheBF

    Dragonstomper

  • Topic Starter
  • 754 posts
  • Location:The Great White North

Posted Sat Apr 21, 2018 8:18 AM

ANS/ISO Forth Files

 

I am in the process of documenting the handle based file system in CAMEL99 Forth.

It seems to work pretty well.  The ANS Forth file words may be a little more primitive than BASIC programmers are used to so I may add a layer on top to make closer to BASIC.

However it is really fun to have a handle based file system on the TI-99.

 

The Spoiler contains the code to implement this subset of forth Files wordset.

More information is here: http://forth-standar...g/standard/file

 

Spoiler


#63 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

  • 3,764 posts
  • Location:Silver Run, Maryland

Posted Sat Apr 21, 2018 12:16 PM

You may have already addressed this and maybe I am missing or forgetting something, but two things puzzle me about PAB and VRAM buffer placement in your handle-based file system for CAMEL99 Forth:

  1. The odd-address starting points referenced to >3FFF and
  2. The overwriting of the reserved disk buffer space of high VRAM tracked by DSRs at >8370 (highest available VRAM address).

Disk DSRs, based on the TI DSR specs for the TI-99/4A, reserve buffer space for the DSR at the top of VRAM, placing the address of the byte just below this space into >8370.  This buffer space changes for each invocation of the DSR’s FILES subprogram, changing the address in >8370 up or down by 518 bytes for each file (at least, that is so for TI, CorComp, MYARC(?), CF7 and nanoPEB DSRs).  It seems to me that your upper reference point for PABs should be the value in >8370 after “ 8 FILES ” (or equivalent) is executed.

 

If you have only tested your file-handle system on Classic99 with its default FIAD file handler, you can probably get away with it, but it will crash and burn on the real iron and emulators that use the actual TI-based DSRs.  This will even happen on Classic99 if you use the TI controller option, which can only be invoked by using a disk image and manually editing the section of the INI file for that particular disk to set Type=3.

 

...lee



#64 TheBF OFFLINE  

TheBF

    Dragonstomper

  • Topic Starter
  • 754 posts
  • Location:The Great White North

Posted Sat Apr 21, 2018 3:09 PM

in order to shoehorn file loading into the 8k kernel I  used a simple decrement the PAB pointer by >120 each time a new file is opened.

This means the PAB pointer defaults to the top of VDP RAM at 3FFF before the first file is opened.

 

So I think what your new information means for me if that I should replace my Forth variable with the address 8370 to properly tell the system that I have taken the VDP memory for myself.

 

Did I get that right?



#65 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

  • 3,764 posts
  • Location:Silver Run, Maryland

Posted Sat Apr 21, 2018 3:40 PM

in order to shoehorn file loading into the 8k kernel I  used a simple decrement the PAB pointer by >120 each time a new file is opened.

This means the PAB pointer defaults to the top of VDP RAM at 3FFF before the first file is opened.

 

So I think what your new information means for me if that I should replace my Forth variable with the address 8370 to properly tell the system that I have taken the VDP memory for myself.

 

Did I get that right?

 

Not unless you are writing your own DSR for peripheral I/O.

 

Upon power-up, the top of VRAM is reserved by the DSR of the first disk device encountered by the 4A and its DSR handles calls for reserving more or less space by the FILES routine.  The DSR uses that reserved space for passing file/sector contents to and from the programmer’s PABs and their associated buffers pointed to by bytes 2 and 3 of each PAB, which are distinct from the DSR’s upper-VRAM buffers.

 

And, I still do not understand starting each PAB area on an odd address.  Do you use a single byte at each starting address for linking or something else?  Oh, wait!—VRAM is only ever byte-addressed, i.e, not directly address by the TMS9900!—never mind!  :dunce:

 

...lee



#66 TheBF OFFLINE  

TheBF

    Dragonstomper

  • Topic Starter
  • 754 posts
  • Location:The Great White North

Posted Sat Apr 21, 2018 5:08 PM

So that is how the machine wakes up but if we load a program with the E/A cartridge, can we not take over the machine and do what we want with the VDP RAM?

 

I am slowly working on getting my real iron running so I guess I get to find out in a while.

 

B



#67 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

  • 3,764 posts
  • Location:Silver Run, Maryland

Posted Sat Apr 21, 2018 5:59 PM

So that is how the machine wakes up but if we load a program with the E/A cartridge, can we not take over the machine and do what we want with the VDP RAM?

 

I am slowly working on getting my real iron running so I guess I get to find out in a while.

 

B

 

Oh, you can, indeed, do whatever you want, just as long as you never attempt to open a file on disk.  But—if you access a disk, the controller to which it is attached will use its reserved VRAM space and tromp all over whatever you may have put there.  There is nothing you can do to tell the disk controller’s DSR to do otherwise short of disconnecting the controller, but, then, of course, you would have no disk access.  In fact, if you trash the validation byte (>AA) just above the address in >8370, disk access may actually not work, at all.  However, I do not know whether the DSR checks that byte before every I/O operation or only at startup to validate that it actually got written.

 

...lee



#68 TheBF OFFLINE  

TheBF

    Dragonstomper

  • Topic Starter
  • 754 posts
  • Location:The Great White North

Posted Sat Apr 21, 2018 7:05 PM

I thought the ROM DSR code used the PAB for its clues as to where the file buffer is located and which device to connect to and all the other details.

 

I used to be confused, but now I am not so sure. :?



#69 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

  • 3,764 posts
  • Location:Silver Run, Maryland

Posted Sat Apr 21, 2018 10:52 PM

I thought the ROM DSR code used the PAB for its clues as to where the file buffer is located and which device to connect to and all the other details.

 

I used to be confused, but now I am not so sure. :?

 

That is mostly true, but the DSR has its own buffer in high VRAM for each open file, which must be different from the buffer to which the PAB points.  The DSR does not check your PAB or the VRAM buffer to which it points to see whether the file is open.  It checks its own buffer(s).  I would need to review the details to be sure, but I believe the DSR always reads and writes whole sectors regardless of the read or write mode requested by the PAB.  Whereas, the PAB’s buffer only needs to be big enough to hold one record, which can be much smaller than a sector.  In fact, it even can make sense for two PABs to point to the same VRAM buffer for copying information from one file to another.  The DSR, however, will use separate buffers for each file.  I guess you could think of the DSR buffers as kind of dumbwaiters that pass file sectors back and forth.

 

I think that, for writes, the DSR does not write a dirty sector buffer until a different sector is accessed or the file is closed.  The fact that there is enough room in each DSR buffer for two sectors probably makes this process more efficient, but I digress...

 

...lee



#70 TheBF OFFLINE  

TheBF

    Dragonstomper

  • Topic Starter
  • 754 posts
  • Location:The Great White North

Posted Sun Apr 22, 2018 8:04 AM

So the file system is double buffering in VDP Ram.  Once at the sector level and then copying records into different VDP RAM.

Sounds pretty inefficient, however I guess we can never accuse the TI-99 designers of worrying too much about efficiency. 

 

This could have been done using the (address, len) structure to manage the date, simply pointing to the data in the sector buffer rather than copying it anywhere.  Maybe that's how I should write a new file system... hmmm

 

Ok so I have to move my buffers much farther up in memory.  But I still don't know where the FILES function is located when I use the E/A cartridge, that allocates this VDP sector memory.  I may spend some time studying the DISK DSR CODE further.

 

Thanks for the insights Lee.



#71 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

  • 3,764 posts
  • Location:Silver Run, Maryland

Posted Sun Apr 22, 2018 11:03 PM

So the file system is double buffering in VDP Ram.  Once at the sector level and then copying records into different VDP RAM.

Sounds pretty inefficient, however I guess we can never accuse the TI-99 designers of worrying too much about efficiency. 

 

This could have been done using the (address, len) structure to manage the date, simply pointing to the data in the sector buffer rather than copying it anywhere.  Maybe that's how I should write a new file system... hmmm

 

Ok so I have to move my buffers much farther up in memory.  But I still don't know where the FILES function is located when I use the E/A cartridge, that allocates this VDP sector memory.  I may spend some time studying the DISK DSR CODE further.

 

Thanks for the insights Lee.

 

No prob.

 

I doubt that the E/A cartridge has a FILES routine.  I think the power-up routine in the DSR sets the default to 3.

 

The FILES function is a level 2 DSR routine.  Its “name” is >16.  Here is the FILES word’s routine for fbForth 2.0 that calls it:

;[*** FILES ***      ( n --- )
*       expects on the stack the maximum number 
*       of simultaneously open files

*        DATA DPTH_N
* FIL__N DATA 5+TERMBT*LSHFT8+'F','IL','ES'+TERMBT

* FILES  DATA $+2
*        BL   @BLF2A
*        DATA _FILES->6000+BANK2  

_FILES MOV  @$PABS(U),R0        ; PAB address
       LI   R1,>0100            ; namelength (1 for DSR subroutines)
       LIMI 0                   ; disable interrupts because VSBW and DSRLNK don't
       BLWP @VSBW               ; write the byte to the PAB
       INC  R0                  ; next PAB address to write
       LI   R1,>1600            ; FILES subroutine number in DSR
       BLWP @VSBW               ; write to PAB
       MOVB @1(SP),@>834C       ; get number of files from stack
       INCT SP                  ; pop stack
       DEC  R0                  ; point to namelength byte in PAB
       MOV  R0,@SUBPTR          ; copy to where DSR expects it
       BLWP @DSRLNK             ; do the subroutine
       DATA >0A                 
       B    @RTNEXT             ; return to inner interpreter
;]* 

I am not checking for errors, but you can check the byte at >8350 for 0 (success) or failure (>FF).

 

...lee



#72 TheBF OFFLINE  

TheBF

    Dragonstomper

  • Topic Starter
  • 754 posts
  • Location:The Great White North

Posted Mon Apr 23, 2018 11:32 AM

 

No prob.

 

I doubt that the E/A cartridge has a FILES routine.  I think the power-up routine in the DSR sets the default to 3.

 

The FILES function is a level 2 DSR routine.  Its “name” is >16.  Here is the FILES word’s routine for fbForth 2.0 that calls it:

;[*** FILES ***      ( n --- )
*       expects on the stack the maximum number 
*       of simultaneously open files

*        DATA DPTH_N
* FIL__N DATA 5+TERMBT*LSHFT8+'F','IL','ES'+TERMBT

* FILES  DATA $+2
*        BL   @BLF2A
*        DATA _FILES->6000+BANK2  

_FILES MOV  @$PABS(U),R0        ; PAB address
       LI   R1,>0100            ; namelength (1 for DSR subroutines)
       LIMI 0                   ; disable interrupts because VSBW and DSRLNK don't
       BLWP @VSBW               ; write the byte to the PAB
       INC  R0                  ; next PAB address to write
       LI   R1,>1600            ; FILES subroutine number in DSR
       BLWP @VSBW               ; write to PAB
       MOVB @1(SP),@>834C       ; get number of files from stack
       INCT SP                  ; pop stack
       DEC  R0                  ; point to namelength byte in PAB
       MOV  R0,@SUBPTR          ; copy to where DSR expects it
       BLWP @DSRLNK             ; do the subroutine
       DATA >0A                 
       B    @RTNEXT             ; return to inner interpreter
;]* 

I am not checking for errors, but you can check the byte at >8350 for 0 (success) or failure (>FF).

 

...lee

 

Well this has forced me to read all the rest of the stuff on the TI Tech pages.  Thanks again Lee.

So It should be pretty simple now for me to call these subprograms by using the language I created for File DSRs.

I believe I just need to search the sub-program list rather than the DSR list.

That's the theory anyway.

 

And we all know that theory and practice are the same ... in theory. 

 

(but not in practice)  :( 



#73 Lee Stewart ONLINE  

Lee Stewart

    River Patroller

  • 3,764 posts
  • Location:Silver Run, Maryland

Posted Mon Apr 23, 2018 11:51 AM

So It should be pretty simple now for me to call these subprograms by using the language I created for File DSRs.

I believe I just need to search the sub-program list rather than the DSR list.

 

Yup.  That is what the 

BLWP @DSRLNK
DATA >0A

does with the >0116 (string length=1 and name=16h) in the PAB.

 

...lee



#74 TheBF OFFLINE  

TheBF

    Dragonstomper

  • Topic Starter
  • 754 posts
  • Location:The Great White North

Posted Sat Apr 28, 2018 1:08 PM

CAMEL99 Forth V2.0.11

 

I have addressed the new information (to me) that Lee provided regarding using >8370 as source of the end of VDP memory.

I have not yet implemented "FILES" so the default value is currently set to 3 by the TI system and there is not way to change it.

 

I am changing editors to ATOM to allow integration with GitHub, but I fear there will be some bad synchronization for a time while I get familiar with these new tools.

However I am enjoying this modern way of doing things. :-)

 

Version 2.0.11 binary is on GitHub in the DSK1 folder.

 

There is also a major upgrade to the manual V0.7 that gives more insight for using the system with more demo programs, Assembler explanations and info on some new faster direct control (not auto-motion) Sprites.



#75 TheBF OFFLINE  

TheBF

    Dragonstomper

  • Topic Starter
  • 754 posts
  • Location:The Great White North

Posted Thu May 3, 2018 2:48 PM

Monkey Fingers

 

You know what they say about monkeys and typewriters and an infinite amount of time?

I am not sure it's true, but this monkey program is entertaining to watch if you are a word nerd.

And if you write science fiction, it comes up with some pretty good character and planet names IMHO.

 

The program has simple rules to prevent multiple consonants and vowels, but no rule for a 1 letter word that is just a consonant.

 

This has been tested on CAMEL99 V2.0.11

 

Spoiler

 

 

 

 

 

Attached Files







Also tagged with one or more of these keywords: Camel99, Forth, Concatentive Programming, ANS Forth

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users