Jump to content

Photo

Camel99 Forth Information goes here

Camel99 Forth Concatentive Programming ANS Forth

274 replies to this topic

#251 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Fri Jan 25, 2019 10:32 PM

Rosetta Code Clock

 

I noticed nobody in the Forth community put up an entry in Rosetta code for a clock so I took some pieces from CAMEL99 Forth and created one.

 

It uses the big letter printing demo, plus the .TIME from the ELAPSED program.  I put in the caveat that the code requires an interrupt driven timer 

with a  1/60 second interval.  It makes a pretty good timer to just wait for the byte at >8379 to change.

 

I had to include a small pattern description table, because the code might be run on another machine than the TI-99.

 

The one neat thing about the code is I use M+ , which takes 2 ,16 bit integers and adds them to create a 32 bit result.

With this I can keep track of 4.1 billion seconds or so on the clock. :)

 

Here is the code:

 

http://www.rosettaco...w_a_clock#Forth



#252 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

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

Posted Sat Jan 26, 2019 4:20 AM

Rosetta Code Clock

   ...

 

 

I must be missing something, but how does your code comply with rule #3 re hogging CPU time?

 

...lee



#253 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Sat Jan 26, 2019 8:34 AM

 

 

I must be missing something, but how does your code comply with rule #3 re hogging CPU time?

 

...lee

Quite right.

 

I considered making it multitasking, but that is not supported in standard Forth.

 

I think to address that I will add PAUSE to the counter loop and note that this prevents CPU hogging.

\  subtract old value from new value until ticker changes.
: 1/60  ( -- )
        TICKER DUP @  ( -- addr value)
        BEGIN
             PAUSE    \ *Gives time to other Forth processes while we wait
             OVER @   \ read ticker addr
             OVER -   \ subtract from old value
        UNTIL
        2DROP ;

I just made the change.  Thanks for keeping me honest.


Edited by TheBF, Sat Jan 26, 2019 8:40 AM.


#254 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

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

Posted Sat Jan 26, 2019 9:51 AM

I think I would code it as/with a user ISR in fbForth, but, then again, I suppose not all Forths support that either.

 

...lee



#255 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Sat Jan 26, 2019 10:30 AM

I think I would code it as/with a user ISR in fbForth, but, then again, I suppose not all Forths support that either.

 

...lee

 

You can always specify which version of Forth is being demonstrated and hi-light FbForth directly.

 

I have been reviewing this code with GForth and I found that yet there more dependencies.

The character table is big-endian for the 9900 so I need to add that and specify a 16 bit CPU as well.

It's never easy with such a low level language. :(



#256 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Sat Jan 26, 2019 10:54 AM

And one more gotcha that applies to both of our systems. 

I have been playing with a very specific TI-99 DEMO of this concept and the forth number conversion buffer is not thread-safe.

I had the Forth console running below the clock and of course when I display a number at the console, the clock messes up.

 

You need to use a specific buffer for each thread. I made a way to do this but broke it by trying to optimize the system with a code word for PAD.  :mad:

 

Edit: I forgot that I had to set a variable in the new task to put the local PAD above Forth's PAD.  duh!


Edited by TheBF, Sat Jan 26, 2019 10:57 AM.


#257 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

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

Posted Sat Jan 26, 2019 12:05 PM

Re the PAD thing:  I would need to do something like was done with the DEMO user ISR in Chapter 10 of my manual.  DEMO was inherited from the TI Forth manual.  It defines the following words to move PAD up before and back down after running the ISR:

: UP 100 ALLOT ;       \ move HERE and thus PAD up 100 bytes
: DOWN -100 ALLOT ;    \ restore PAD to its original location

...lee



#258 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Mon Jan 28, 2019 8:19 PM

TTY Terminal for CAMEL99 Forth

 

Ever since I got a copy of TI Forth back in 1984 (85?)  I wanted to be able to use the RS232 ports to control the TI.

My PC keyboard was always nicer to work with and I had 2 serial ports on the darn machine just sitting there since my dot matrix printer ran on the PIO port.

 

I have been studying on how best to this and keep the whole thing in an 8K kernel.  It turns out that Assembler takes a lot less space for CRU operations since I don't need the overhead of the Forth CRU commands loaded into the system. And as I have mentioned the semantic power of 9900 Forth assembler is about the same as Forth for low level operations anyway and it goes faster.

 

The big concern is always dropping characters on receive.  With the little receive routine in the spoiler I found I could send continuous characters at 9600 and echo them onto the VDP screen and only drop chars during a screen scroll. So for typing this is no concern. 

 

For sending text programs to Forth I need to wait for the echo back from Forth on each character and add a small delay on a newline. If I do that I will never overrun the input. I have done this in the past with 68HC11 embedded Forth and it works fine.

 

The weird thing is how much more responsive the keyboard is without all that code the runs in KSCAN. 

It's not bullet proof yet but I will get it there because I like this way of working.  The old CRT monitor will have to move over to this desk now.

 

Note: my configuration code below is very ugly but I was just trying to make a compact word. It's on the chopping block.

 

Spoiler

Attached Files



#259 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Mon Jan 28, 2019 8:26 PM

The rest of the TTY interface for those who are interested. 

Is SIGNIFICANTLY smaller than doing the same thing for VDP and KSCAN 

\ TTY OUTPUT is done with EMIT
: EMIT  ( char  -- ) \ replaced with code version: TI99PRIM.HSF
          TTYEMIT
          1  OUT +!
          1 VCOL +! ;

: CR    ( -- ?)
         0D EMIT 0A EMIT  
         OUT OFF  VCOL OFF
         1 VROW +!  ;

: PAGE    ( -- )  0C TTYEMIT  OUT OFF  0 0 AT-XY ;
: TYPE    ( adr cnt --) BOUNDS ?DO  I C@ EMIT  LOOP ;
: SPACE   ( -- )   BL EMIT ;
: SPACES  ( n -- ) 0 MAX  0 ?DO SPACE LOOP ;

\ =========================================
\ Forth input use KEY , which calls TTYKEY
: KEY        ( -- char) TTYKEY ;

\ High level: input/output                    (c) 31mar95 bjr
: ACCEPT      ( c-addr +n -- +n')            \ get line from terminal
             OVER + 1- OVER
             BEGIN  KEY DUP 0D <>            \ test for enter (hex D)
             WHILE
                DUP EMIT 
                DUP 8 =                        \ test for back-space character
                IF   DROP 1-  >R OVER R> UMAX  \ move the buffer pointer back
                ELSE OVER C!  1+ OVER UMIN
                THEN
             REPEAT
             DROP NIP SWAP -  ;


#260 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Wed Jan 30, 2019 8:17 PM

One day I may stop using a homemade compiler...

 

But in the meantime, I have Forth's interpreter running over RS232 beautifully but the compiler is broken. 

The problem is somewhere in the routine that builds the dictionary data structure but I am damned if I understand why.

I also noticed that my stack dump word was broken as well. So I have two clues to find what I have broken.

 

 

Attached Files



#261 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

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

Posted Wed Jan 30, 2019 9:42 PM

I have not spent enough time with your compiler to be able to offer much help.  The only thing that comes to mind is whether any words in your TTY interface redefine existing words that might get called by the compiler or DUMP code.  If that is the case, the original definitions might confuse things when they get executed instead of their new counterparts.

 

...lee



#262 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Thu Jan 31, 2019 7:01 AM

I have not spent enough time with your compiler to be able to offer much help.  The only thing that comes to mind is whether any words in your TTY interface redefine existing words that might get called by the compiler or DUMP code.  If that is the case, the original definitions might confuse things when they get executed instead of their new counterparts.

 

...lee

That's a good thought.  Since my first attempts I have redefined KEY and EMIT as the actual code words rather than calling them as primitives.

This greatly simplified things and the problem existed in the previous version.

 

But I think there is some hidden thing going on regarding my .S breaking and the HEADER word that makes the dictionary entry.

It points to some underlying thing that I don't know about.  

 

I will double check against your idea to see what I missed there.

 

I will have to make a tool to display whats happening in the header work while it executes.

 

Brief story with my coffee:

 

I called the founder of New Micros, Randy Dumse, years ago to get some help with a agricultural project I built on one of his 68HC11 boards.

After my description he said "Well, it sounds like you know what you are doing. Did I give you my man is toolmaking animal lecture?"

 

I said "No".

 

He said "Well here it is."

 

"Man is a toolmaking animal. Make a tool." 

 

and he hung up.  :D



#263 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Mon Feb 4, 2019 11:17 AM

Dead bugs make me happy

 

So after doing a pretty big overhaul of the RS232 code I got things working. I still don't fully understand what was fooling the cross-compiler into making wrong code but it was no doubt an error on my part that does not flag an error from the cross-compiler during compilation.  When I write correct code it seems to behave.  I will find that little devil eventually.

 

I thought I would take some time to explain one way to do vectored I/O  on a Forth system since that is what I have been striving to achieve. 

I know that TI-Forth was capable of this but to be honest I did not understand it in the early 1980s.  It was not until I bought a commercial Forth system that I got clarity on how it worked. Like all things inside Forth its simple.

 

Traditional Forth I/O 

 

Forth systems have at a minimum only two I/O routines. More are possible, but for this explanation let's keep it to two.

 

They routines are called KEY and EMIT.   KEY waits for an input character and EMIT sends a character.  

For each computer system there is a way to do those simple functions so most of the time you just have to make a call to the operating system to get a character and send a character to the default I/O device.

 

On TI-99 of course it's the VDP chip that we use for EMIT so writing up a little routine that takes a byte from the Forth stack and puts it into VDP memory is pretty simple. It's mostly VSBW.

We just need a few variables to remember where the cursor is.

 

For Forth's KEY we literally branch and link to the KSCAN, read a character from the byte buffer and put it on the top of the Forth stack, ready for some code to use.

 

KEY and EMIT are then used throughout the system to write any routine that gets or sends characters to the "standard I/O" devices. 

For example ACCEPT reads a string of characters and it uses KEY internally. TYPE prints a string and it uses EMIT internally.

If you consistently use KEY and EMIT in all your high level I/O routines everything just works. It's easy. It's not always the fastest, but it works.

 

Different I/O Devices

So all that is great until you want to use a different I/O channel. What to do?

 

The secret is to use variables to hold the "execution token" (XT) of an I/O routine and use EXECUTE to run that XT.

Below is an example of how EMIT can become different routines, but still have the name "EMIT" in your Forth program.

VARIABLE 'EMIT   ( Called "tick emit" Holder for the execution token, ie: the XT) 

\ This is all it takes to make a "vectored" EMIT routine
: EMIT  ( c -- ) 'EMIT @  EXECUTE ;  ( fetch the token from the variable and run it)

\ write the code to write a byte to different devices
: VDP-EMIT  ( c -- ) ( code like VSBW to put a character on the screen) ;
: PIO-EMIT  ( c -- ) ( BLAH BLAH BLAH CODE TO SEND BYTE TO PRINTER )  ;
: TTY-EMIT ( c --) ( CODE TO SEND BYTE TO SERIAL PORT ) ;

\ create commands to change the XT held by 'EMIT 
: >CONSOLE         [']  VDP-EMIT  'EMIT !  ;     \ lookup the XT of VDP-EMIT and store in variable 'EMIT
:  >PIO            [']  PIO-EMIT   'EMIT ! ;
:  >TTY            ['] TTY-EMIT   'EMIT ! ;

So in the attached video you are seeing this in action. 

In this version of CAMEL99 Forth I have created "vector" variables for EMIT, KEY and CR (newline command).

 

I have written a Forth Assembler routine to send a byte called CEMIT (com emit). 

There is also a routine called CKEY, (com key) which is multi-tasking friendly and there is also a routine called CCR ( com carriage return).

CCR is needed because a newline on a terminal send a carriage routine and line-feed character whereas on the TI-99 it moves the cursor in position in VDP memory. So I vectored that as well. 

 

The end result is that I can send and receive data from Forth on the TI-99 over RS232 and that also means I can send source code and have it compile and/or interpreted from the PC as well.   :)

 

There are more details to consider here but I thought someone might like to know how this works and where I am taking CAMEL99 Forth.

Attached Files


Edited by TheBF, Mon Feb 4, 2019 11:20 AM.


#264 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

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

Posted Mon Feb 4, 2019 7:06 PM

...

Different I/O Devices

So all that is great until you want to use a different I/O channel. What to do?

 

The secret is to use variables to hold the "execution token" (XT) of an I/O routine and use EXECUTE to run that XT.

Below is an example of how EMIT can become different routines, but still have the name "EMIT" in your Forth program.

VARIABLE 'EMIT   ( Called "tick emit" Holder for the execution token, ie: the XT) 

\ This is all it takes to make a "vectored" EMIT routine
: EMIT  ( c -- ) 'EMIT @  EXECUTE ;  ( fetch the token from the variable and run it)

\ write the code to write a byte to different devices
: VDP-EMIT  ( c -- ) ( code like VSBW to put a character on the screen) ;
: PIO-EMIT  ( c -- ) ( BLAH BLAH BLAH CODE TO SEND BYTE TO PRINTER )  ;
: TTY-EMIT ( c --) ( CODE TO SEND BYTE TO SERIAL PORT ) ;

\ create commands to change the XT held by 'EMIT 
: >CONSOLE         [']  VDP-EMIT  'EMIT !  ;     \ lookup the XT of VDP-EMIT and store in variable 'EMIT
:  >PIO            [']  PIO-EMIT   'EMIT ! ;
:  >TTY            ['] TTY-EMIT   'EMIT ! ;

...

 

Ti Forth and fbForth have two user variables for alternate I/O for KEY and EMIT .  They are ALTIN and ALTOUT for KEY and EMIT , respectively.  If the value is not 0, then it must point to the PAB address in VRAM of the I/O device—usually RS232 or PIO, which must have a one-byte I/O buffer immediately preceding the PAB.

 

However, if a facility similar to the one you describe for Camel99 Forth were to be provided for Ti Forth and fbForth, it would have the following code à la figForth/Forth-79:

VARIABLE 'EMIT   ( Called "tick emit" Holder for the execution token, ie: the XT) 

\ This is all it takes to make a "vectored" EMIT routine
: EMIT  ( c -- ) 'EMIT @  EXECUTE ;  ( fetch the token from the variable and run it)

\ write the code to write a byte to different devices
: VDP-EMIT  ( c -- ) ( code like VSBW to put a character on the screen) ;
: PIO-EMIT  ( c -- ) ( BLAH BLAH BLAH CODE TO SEND BYTE TO PRINTER )  ;
: TTY-EMIT  ( c -- ) ( CODE TO SEND BYTE TO SERIAL PORT ) ;

\ create commands to change the XT held by 'EMIT 
: >CONSOLE  ' VDP-EMIT CFA 'EMIT ! ;   \ lookup the XT of VDP-EMIT and store in 'EMIT
: >PIO      ' PIO-EMIT CFA 'EMIT ! ;   \ lookup the XT of PIO-EMIT and store in 'EMIT
: >TTY      ' TTY-EMIT CFA 'EMIT ! ;   \ lookup the XT of TTY-EMIT and store in 'EMIT

...lee



#265 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Mon Feb 4, 2019 8:41 PM

Thanks for the translation code Lee.  I now remember seeing ALTIN and ALTOUT in screen code. I must have got it working because my old dot matrix printer worked.

 

So after I got the colon compiler working and the vectored I/O and did this little video recording I was very pleased and posted here.

 

Next I tried loading a file from TI disk... <ugly music plays here>  :woozy:

 

I am looking over some things to find the error in my ways.  I am using the same DSR file for both kernel builds however.

I may have to resort to building a TI-99 kernel, add in the Vectored Serial I/O, save it all with Classic99's utility and see what gives from within Forth on the standard I/O devices on the old hardware.

 

My amateur status is showing.  It's a humbling hobby as I have said numerous times before.



#266 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Wed Feb 6, 2019 8:13 AM

I am considering opening a new store called Bugs R Us

 

In my previous serial port testing I had included a "tool" file that I had used in the past for working on the system. It is written in Cross-compiler Forth and I thought it was bug free.

 

I removed it from the build to simplify things and lo and behold I can now compile code from floppy disk, while controlling the TI-99 over the serial port.

 

I have simplified the overall code that does the interface.  To support multi-tasking I need to have the receive routine KEY written in Forth, so the ALC code word does not loop, rather it tests one bit to see if there is a character in the 9902 RX register. If there is it reads it to the top of Forth stack.  If not it just exits.  This allows a very simple and classic implementation of KEY in Forth.

 

I don't know if it matters but I am saving R12 on the Forth return stack and restoring it between operations.  This is actually slightly faster than that using BLWP (28+22=40 cycles)

I did this to eliminate any possibility of corrupting other I/O operations while talking over RS232.

 

Question:   Ideally I want to handshake off when I detect a character since I don't have receive interrupts. Not sure how that is done.  (set RTS on maybe?)

CODE: CKEY? ( -- n )          \ fast tty read
          R12 RPUSH,
          PORT @@ R12 MOV,    \ select the 9902
          TOS PUSH,
          TOS CLR,
          21 TB,              \ test if char ready
          EQ IF,
              TOS 8 STCR,     \ read the char
             TOS 8 SRL,       \ shift to other byte
                18 SBZ,       \ reset char buffer
          ENDIF,
          R12 RPOP,
          NEXT,
          END-CODE

: ?TERMINAL ( -- ?) CKEY? 3 = ;       \ ^C will be "break" key

: KEY        ( -- char) 
              BEGIN
                PAUSE                 \ multi-tasking switch
                CKEY?                 \ test for key
                ?DUP                  \ dup if not zero
              UNTIL ;                 \ char is on stack if loop exits

For anyone who needs a programmable terminal for Windows I have found Terra Term.  It is very good. One downside, it does not seem to have an Xmodem transfer mode for use with Magic File Manipulator.

 

The attached video shows compiling from floppy disk  while using Terra Term to control the machine.  I couldn't help configuring it to look like TI BASIC. :-)

 

 

 

 

Attached Files



#267 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Sun Feb 10, 2019 3:33 PM

I am having some fun (and bugs) controlling Forth over the serial port. The final code to access the serial port is in the spoiler below.

I only flash the RS232 CARD led during transmit because that is under TI-99 control. On receive, without interrupts I want the code as lean and fast as possible.

 

NOTE: This is not ANS Standard Forth, it is my CROSS-COMPILER Forth which uses some special incantations to tell Forth when to compile for TI-99 and when to change things in the PC that's doing the compiling. I changed some standard words like 'constant' to have an extra colon to help me keep track of which machine I am talking to in the code. (I need all the help I can get)

 

Spoiler

 

I can send code to Forth over RS232 and compile programs but without interrupts its slow. Terra Term is set to delay each character by 1 ms and each line delays 300mS to be sure the old 99 has time to compile the line.  

 

I have 2 options to fix that.  

  1. Figure out how to write a Terra Term script that send text programs and waits for the echo back from Forth, and waits for 'ok' back from Forth after a newline.
  2. Use the interesting interrupt stealing method shown in tech pages and force the old machine to keep up.

I have also had a change of heart on adding the final ANS Forth words to the system on startup with a floppy disk. 

I have changed from loading each small file one a time to putting all the definitions in a new file called "SYSTEM". This makes the system start much faster.

 

The Video below shows the system booting from floppy disk and loading SYSTEM and the VT100 terminal control library.

 

It's kind of fun having two screens on the TI-99.  I ran a demo program that uses Graphics mode 1 to produce color bars .

Graphics on the old CRT and text interpreter control on the PC.

 

It's what I wanted 30 years ago...

 

 

 

Attached Files



#268 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Mon Feb 11, 2019 10:56 AM

VT100 Terminal Control in Forth
 
Somebody somewhere might have a use for this code.  I chose to create a kind of markup language to do this job.
The last line is for "vectored execution" .  In your system you would need the following to make It work.
xx is the number of your system's USER variable.
 
NOTE:  You can use a regular variable in a single threaded system


xx USER 'PAGE  \ variable that hold execution address

: PAGE   'PAGE @ EXECUTE ;   \ get routine's address and do it

 

CR .( VT100 terminal control)
DECIMAL
\ type a number in base 10, with no space
: <ARG>   ( n -- )
           BASE @ >R  
           0 <#  DECIMAL #S  #> TYPE
           R> BASE ! ;

\ markup language for terminal control codes
: <ESC>[  ( -- )   27 EMIT  91 EMIT  ;
: <UP>    ( n -- ) <ESC>[ <ARG> ." A" ;
: <DOWN>  ( n -- ) <ESC>[ <ARG> ." B" ;
: <RIGHT> ( n -- ) <ESC>[ <ARG> ." C" ;
: <BACK>  ( n -- ) <ESC>[ <ARG> ." D" ;
: <HOME>  ( -- )   <ESC>[ ." 0;0H" ;
: <CLS>   ( n -- ) <ESC>[ ." 2J" ;
: <CLRLN> ( -- )   <ESC>[ ." K" ;

\ redefine Forth words using markup words
: AT-XY   ( col row --) 
          2DUP VROW 2!
          SWAP <ESC>[ <ARG> ." ;" <ARG> ." f" ;

: TTYPAGE ( -- ) <CLS>  <HOME> ;

CR .( Set PAGE vector for VT100)
' TTYPAGE  'PAGE !


Edited by TheBF, Mon Feb 11, 2019 10:59 AM.


#269 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Wed Feb 13, 2019 8:36 AM

I am having fun using my new terminal interface to 99. It will be better once I get the rcv side running with an interrupt but it is still useful as is.

 

I have just discovered the game bar recorder on Windows 10 so now I can add a little commentary to my videos. Turn off the sound if it is too painful to listen to. :-)

 

It's time to create a youtube channel for these things I guess.

 

https://www.youtube....h?v=Ao0stVFFl3Q

 

 

BTW, did you notice that we built some assembly language code from the console and could use it immediately?  

Interactive Assembly language is a Forth super power IMHO.

 

Edit: added the code here

\ simple ISR counter example

NEEDS DUMP FROM DSK1.TOOLS
NEEDS MOV, FROM DSK1.ASM9900

VARIABLE X
CODE COUNTER ( -- ) \ example ISR
     X @@ INC,
     RT,
     ENDCODE

: ?CODE ( cfa -- ) DUP @ 2- - ABORT" Not code word" ;

\ API LAYER
: ISR'  ( -- code-address)
        BL WORD  FIND  0= ABORT" ISR not found"
        DUP ?CODE >BODY ;

: INSTALL   83C4 ! ;   \ Usage: ISR' COUNTER  INSTALL

Edited by TheBF, Thu Feb 14, 2019 4:03 PM.


#270 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Thu Feb 14, 2019 4:17 PM

And while we have a way to hook the interrupt, how about a 32 bit timer.

This can count to 4,294,967,296 ticks before rolling over.  That's  19,884 hours or 2.26 years! :-)

Never left my old TI-99 running that long. 

CREATE TIME32 0 , 0 ,

CODE DOUBLECOUNT
         TIME32 CELL+ @@ INC,
         OC IF,
              TIME32 @@ INC,
         ENDIF,
         RT,
         ENDCODE
\ to see the time value use: TIME32 2@ DU. 


#271 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

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

Posted Thu Feb 14, 2019 6:04 PM

And while we have a way to hook the interrupt, how about a 32 bit timer.

This can count to 4,294,967,296 ticks before rolling over.  That's  19,884 hours or 2.26 years! :-)

Never left my old TI-99 running that long. 

CREATE TIME32 0 , 0 ,
CODE DOUBLECOUNT
         TIME32 CELL+ @@ INC,
         OC IF,
              TIME32 @@ INC,
         ENDIF,
         RT,
         ENDCODE
\ to see the time value use: TIME32 2@ DU. 

That is really tempting to add to the fbForth 2.0 ISR, but alas, I fear I have already crammed too much code into that ISR.

 

...lee



#272 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Thu Feb 14, 2019 6:46 PM

 

And while we have a way to hook the interrupt, how about a 32 bit timer.

This can count to 4,294,967,296 ticks before rolling over.  That's  19,884 hours or 2.26 years! :-)

Never left my old TI-99 running that long. 

CREATE TIME32 0 , 0 ,
CODE DOUBLECOUNT
         TIME32 CELL+ @@ INC,
         OC IF,
              TIME32 @@ INC,
         ENDIF,
         RT,
         ENDCODE
\ to see the time value use: TIME32 2@ DU. 

That is really tempting to add to the fbForth 2.0 ISR, but alas, I fear I have already crammed too much code into that ISR.

 

...lee

 

I was not aware of that.

 

What have you got running on it now?



#273 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

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

Posted Thu Feb 14, 2019 7:23 PM

I was not aware of that.

 

What have you got running on it now?

 

I suppose it is not all that much when there is no speech or sound but here it is for your delectation:

 

Spoiler

 

There are three entry points, so all of the code is not executed at every interrupt, but still ...

 

...lee



#274 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Thu Feb 14, 2019 7:59 PM

Ya that could be quite a few cycles worst case. However, adding that 32 bit counter would be a pretty small increase as a percentage of load.

If you decide to try it, do a double check on the cell order of 2VARIABLES in FigForth.  It might be reversed to ANS. (?)

 

Topic shift. 

I am considering adapting my sound control to use this ISR hook to decrementing 4 delay values for the 4 voices.

That will be a very simple way to have background sound.  Set-up the freq. and level and set a delay variable for that voice. Then the interrupt counts it down to zero while the code continues.

 

With that feature I can finish my music script language and actually write polyphonic music.  

 

(Working on the RS232 interrupt code. Just realized that I forgot I was in a different workspace when I wrote my idea of how to enqueue the characters. DUH!.  Used R8 instead of R4.  I am hoping this gets it working)



#275 TheBF OFFLINE  

TheBF

    Dragonstomper

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

Posted Yesterday, 9:03 PM

Make a Tool
Now that I am working on real hardware again it became clear that I need more tools. Tursi has spoiled me with Classic99.
 
One such tool is a DUMP utility to see memory. The spoiler below shows how I wrote mine. I used the DOS debugger dump function as my example for better or worse. It works great but... the TI-99 has VDP memory and I have a fancy new SAMS card.  This DUMP utility cannot cope with these.

 

What's a fella to do?

Spoiler

 

Answer: DEFER 

 

ANS Forth standardized a defining word called DEFER that let's you create a routine that does nothing. :-)

That is until you give it something to do as shown below.

Example:

DEFER TEST
TEST 
*Un-defined DEFER"  \ CAMEL99 DEFERRED init to this behaviour

' WORDS IS TEST 

\ now invoking TEST will run the WORDS utility showing all the system commands.

How will deferred words help fix DUMP?

If you look at DUMP you will see it uses  @ (fetch an integer)  and the .ASCII routine uses C@ (fetch a character)

 

I created two deferred words, MEM@   and MEMC@, and I replaced the originals with these new deferred words.

Now all I have to do is set MEM@ and MEMC@ to the correct memory operator before I run DUMP and voila!  I can see all my memory spaces (well except GROM, but I could do that too if I wanted to)

 

Here is the additional code that does the job:

DEFER MEM@
DEFER MEMC@

: DUMP    ['] @  IS MEM@    ['] C@  IS MEMC@  (DUMP) ;
: VDUMP   ['] V@ IS MEM@    ['] VC@ IS MEMC@  (DUMP) ;
: SDUMP   ['] @P IS MEM@    ['] C@P IS MEMC@  (DUMP) ;

Note: (DUMP) is the renamed DUMP code.

The brackets are Forth naming convention meaning that this is not to be used as is but is a support routine. 

 

You can see in each DUMP word that we lookup the execution of address of each memory operator with ['] 

Then we use IS to assign it to the DEFERRED word. Then we run (DUMP).

 

I'm back in business... until next time I hit a stumbling block.

 

 

 

 

Attached Files







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

1 user(s) are browsing this forum

0 members, 1 guests, 0 anonymous users