Foxit - in progress

[+TheBF]

17 minutes ago, Willsy said:

Yeah in TF you'd need AL words for SBO SBZ and TB. I have them somewhere. Might be on my old laptop - I run a linux box exclusively these days. I'll try and find em.

Actually I have what I need in the code I posted for CRU bit control.

But's impossible to run Forth words on CRU I/O when NEXT is in R12.  You can only do Assembler words.

[GDMike]

24 minutes ago, TheBF said:

This is the ideal way to go IMHO. In fact @GDMike you don't even actually need SAMS if you go that way.

4K blocks of code would come into memory so fast that the program would be usable with out SAMS.

 

I was thinking that Same thing.. just import, I call it, the routine I need run and pull it in. I really need this.

[+Lee Stewart]

2 hours ago, Willsy said:

 So, it (Classic99) doesn't do 1MB SAMS any more?

I guess I can produce a new version of >MAP that gets around the issue.

 

Looks it would become 10 bytes shorter...

 

You would only need to add

       SWPB R2      reverse byte order for poking SAMS reg

before writing to the SAMS reg

 

...lee

[+Lee Stewart]

1 hour ago, TheBF said:

Actually I have what I need in the code I posted for CRU bit control.

But's impossible to run Forth words on CRU I/O when NEXT is in R12.  You can only do Assembler words.

 

Not if you save/restore R12 in each routine. Of course, that bloats the code a bit.

 

...lee

[+TheBF]

1 hour ago, Lee Stewart said:

 

Not if you save/restore R12 in each routine. Of course, that bloats the code a bit.

 

...lee

So I guess you need to create a virtual R12 that holds the working CRU address and a bunch of CRU primitives in Assembler,  that save R12, set R12, do their thing and then restores R12.

 

[GDMike]

I'll be all over foxit Tonight with testing the, "import df80 code"  and seeing how far I can take it.. unfortunately, I'll have zero internet access my whole time..so I can't report until Sunday...

But if it's a fail I'll have my TF  manual with me to study. Lol

[+TheBF]

Don't forget it.

 

[GDMike]

I had issues .. 

I've got to read up on what the EA book says about opcode "LOADER". 

Edited January 24, 2022 by GDMike

[+TheBF]

6 hours ago, GDMike said:

I had issues .. 

I've got to read up on what the EA book says about opcode "LOADER". 

Some things I learned that I put in my SAVELOAD library. Maybe it will open some doors?

 

These are the file modes that work. Use "13" as the mode for program files and the other two numbers to save and load binary data files into VDP RAM. (screens, fonts, sprites etc)

\ file access mode selectors for default file binary type
HEX
0B CONSTANT W/O100  \ WRITE ONLY, binary, relative, fixed 100
0D CONSTANT R/O100  \ READ ONLY,  binary, relative, fixed 100
13 CONSTANT PROG    \ a program file

Here is how I setup a PAB to use LOAD or SAVE

This is all using my internal "language" for accessing a PAB, but hopefully it's self-explanatory as to what goes where in the PAB. 

Important to set the record length field to 0.

 

*difference from TF*

VC! means VDP char store in my system

V!  means VDP integer store so you need to write 2 bytes. 

 

( file$ len)  is what happens when you take a byte counted string in memory <4>"HELP"  and do COUNT on it.

You get the address of the first letter on the stack and the number of bytes on top of it. 

 

You can ignore the ^PAB stuff. I create a stack of PABs and file buffers in VDP so you don't need that. Just use what ever TurboForth provides to set up a file PAB. 

: NEWPAB   (  file$ len VDPaddr #bytes mode -- )
           -30 ^PAB +!         \ create new pab in VDP RAM with NO buffer
           [PAB 30 0 VFILL     \ erase PAB and file name
         0 [PAB RECLEN] VC!    \ set reclen (0 means >100 (256) bytes)
         \ pulls params from the stack to init the PAB
           [PAB FLG] VC!       \ set file access mode byte
           [PAB REC#]  V!      \ set #bytes to save (integer)
           [PAB FBUFF] V!      \ set where the file will load VDP Ram
           [PAB FNAME] VPLACE  \ set file name
;

Then to Load or save stuff in or out of VDP RAM, I just have to do this. (for a program change the mode constant of course)

ior  means I/O response (error message)

: SAVE-FILE ( file$ len VDPaddr size -- ior)
       W/O100 NEWPAB  6 FILEOP  30 ^PAB +! ;

: LOAD-FILE ( file$ len VDPaddr size -- ior)
       R/O100 NEWPAB  5 FILEOP  30 ^PAB +! ;

 

If it is of any value to have these PAB record words, they are pretty simple:

VARIABLE ^PAB  \ pointer to the vdp ADDRESS of the active PAB

: [PAGE     ^PAB @ ;    \ return the VDP address of the active pab.

 

The rest of the words just add a number to the VDP PAB  base address to get to the right field.

:  FLAG]    1+ ; 

:  FBUF]    2+ ;

 

Some would say it's wasteful but it's how I make Forth readable 6 months after I wrote it.   

 

You can finish the rest.  

 

 

 

 

 

 

[Willsy]

14 hours ago, GDMike said:

I had issues .. 

I've got to read up on what the EA book says about opcode "LOADER". 

What is it you're trying to do?

[GDMike]

In my assembly program, I have run out of program space and I still have routines that need to be added.

I'm using SAM'S and my first routine that IS included in the assembly process is pushed to high ram (>F000) as a temporary holding spot until the assembly process is complete and the SAMs mapper can start up(program start), then I moved that routine into SAMs bank>FE00(something like bank 245 or so), and as my program continues to run and if I need that particular routine to run I can just map to it and do a BL @>3000(since my mapper is mapped using address >3000.

that is great and works well.

 

but I cannot do that for my other 3 routines that each use about 2-3K of code. But I cannot include it with the first routine, so I wanted a way to "import" object code that I've preassembled and included a AORG >3000 in it's structure, then at my user request within my MAIN program would, hopefully, LOAD my independently assembled routine, (whichever routine I needed at the time), and would have separate PABs for, would then allow me to do a BL >3000 and I'd have a WS saved prior to the Branch and RT back to that address at a particular Key press in the subroutine.

 

so far, I'm using >0,0,0,0 in my PAB and when I BLWP @LOADER I see only the first line of assembled code on the screen (hex object code ending with 01), I think it says 01 or 001, can't remember without going back to it, but anyway, I'm suspecting that only 1 line of code was loaded? Because I BL or even a B @>3000 was unsuccessful.

I haven't had time lately to figure out if the data really was pushed (pulled?) Into>3000 but.im looking for a way to do that as well..I'm using classic 99, I haven't had time to look at the debugger either...my bad. Because my time is limited like crazy...I have time to try some code, do some troubleshooting, and after a day or so finally get home to my internet where I can report.. blah blah...

funny, I have 2 laptops sitting here doing nothing at home, 1 pc running my cameras for the house, 1 raspberry pi sitting running in my PEB and is waiting for love, but because I'm coding with CL99, I can only push good code to that pi and test on real HW once in awhile, but it's there, and another PC for my steam FS account, another PC for my personal use with LT0 backup.. 

so what I'm saying..I'm outta desk space..so I do most of my TI coding off property and there's no internet nor phone service. So when I make a change to my program or run into trouble, it'll take a couple days to get back into the game again.. plus I'm raising 2 kids by myself and have lots of housewife chores. Lol.

 

I could get remarried, but they'll throw out my computer hobby.hmmm not gonna happen. 

thx for trying to understand why I'm losing my train of thought.. and of course .I gotta run..

raking the backyard today... fixing a water leaking ceiling.. never ends.. but I'm having fun!

 

 

 

 

Edited January 24, 2022 by GDMike

[GDMike]

Finished my backyard..yay.

Ok, so TF would not have this problem with running low because SAMs is started right off the bat in my application.

So, Im thinking it's best to stop toying with assembly just to get past one obstacle.

So there, I've said it. I'll scrap foxit assembly process and start on Forth Foxit. 

I think I've learned quite a bit in Forth to proceed but I've got to start with getting a flashing cursor that leaves a key value on the stack. And I've got that "word" built from a couple years ago because the KEY and KEY? words don't do what I need. Because I want to control the repeat rate, the auto repeat key press and key status, I do have that built, so I'll just start with that, I'll have to build a command window, similar to what I had in assembly foxit...hmm can I use Forth command interface? But I only want that to see the words I CREATE. So il somehow need my own dictionary, I guess that's how I need to start..

No, that won't work..I need to create a dictionary ONLY for related words for Foxit, like table searches, database creation and modification, and well, just words related to foxit. Can I have 2 hidden dictionaries? With 1 only Active when I finish writing foxits basics?

Edited January 24, 2022 by GDMike

[+Lee Stewart]

1 hour ago, GDMike said:

I need to create a dictionary ONLY for related words for Foxit, like table searches, database creation and modification, and well, just words related to Foxit. Can I have 2 hidden dictionaries? With 1 only Active when I finish writing Foxit‘s basics?

 

Making a particular dictionary the CONTEXT dictionary (the one searched) does not necessarily preclude the listing of other dictionaries. It merely lists the CONTEXT dictionary first. It also prevents use of other dictionaries’ words from being invoked if they have the same names as words in the CONTEXT dictionary. Listing of words depends on the dictionary tree. The FORTH dictionary is at the top of the tree so it is always listed (unless you interrupt the listing) as the top level dictionary (last one listed).

 

TurboForth, however, does not have dictionaries (fbForth, TI Forth, CAMEL99 Forth do). TurboForth does have something @Willsy calls Applications Support, which he says is similar, so you may want to read up on that and he will be along to help, shortly, I am sure. 

 

...lee

[+TheBF]

I spent a lot of time working on different ways to do a repeating key in Forth for TI-99 so I have relics around here.

 

This is the repeating key from the  TI FORTH editor that I have modified a bit and made to work with TurboForth.

You need to make a way to change your cursor character inside the words CURSON & CURSOFF  using DEFCHAR or by changing the actual cursor character

and you need a way to put the cursor character on the screen at the current cursor position.  

 

Notice KKEY?  which changes TF KEY? into something more standard , where no key pressed returns zero. 

\ GKEY from TI-Forth ported to TurboForth B Fox
( 64 COLUMN EDITOR  15JUL82 LAO )  DECIMAL

: ENDIF  [COMPILE] THEN ; IMMEDIATE

: CURSOFF   ;  \ fix these for your cursor character
: CURSON    ;

10 CONSTANT RL
40 CONSTANT RH
 VARIABLE BLINK    VARIABLE OKEY
 VARIABLE KC       VARIABLE RLOG

: BLINKER ( -- )
  1 BLINK +! BLINK @ DUP 60 < IF CURSON ELSE CURSOFF ENDIF
  120 = IF 0 BLINK ! ENDIF ;

\ return 0 with no key pressed
: KKEY? ( -- char|0)  KEY? DUP -1 = IF DROP 0 THEN ;

: GKEY BEGIN
       BLINKER
       KKEY? ?DUP
       IF ( some key is pressed ) KC @    1 KC +!  0 BLINK !
          IF ( waiting to repeat ) RLOG @  KC @ <
             IF ( long enough ) RL RLOG !  1 KC ! 1 ( FORCE EXT)
             ELSE OKEY @ OVER =
               IF ( need to wait more ) DROP 0
               ELSE 1 ( force exit )    DUP KC !   ENDIF
             ENDIF
          ELSE ( new key ) 1 ( force loop exit )  ENDIF
        ELSE ( no key pressed) RH RLOG ! 0 KC !   0
        ENDIF
       UNTIL DUP OKEY ! ;

: TEST  BEGIN  GKEY DUP EMIT  65 =  UNTIL ;

 

 

 

 

[GDMike]

Thx. I'll try to dig up my old code and display it. 

From the top of my head, I'm using row, col, getchar, keychar, and I'm not sure what else..

Because as I move I need to read the character at that position, save it, place my cursor character, check for key press, place a timer, place key char if pressed, place my getchar (old character), check for key press, place timer..

I think

[+TheBF]

Just now, GDMike said:

Thx. I'll try to dig up my old code and display it. 

From the top of my head, I'm using row, col, getchar, keychar, and I'm not sure what else..

Because as I move I need to read the character at that position, save it, place my cursor character, check for key press, place a timer, place key char if pressed, place my getchar (old character), check for key press, place timer..

I think

Sounds like the correct method.

[GDMike]

Of course then deal with auto repeat. And that code I have works very well, and I tried to duplicate it last week and couldn't.go figure, but eventually I did find a copy of the code. Lol.. BTW..I'll be working on my ceiling tomorrow...dang it. 

Edited January 24, 2022 by GDMike

[HOME AUTOMATION]

6 hours ago, GDMike said:

so far, I'm using >0,0,0,0 in my PAB and when I BLWP @LOADER I see only the first line of assembled code on the screen (hex object code ending with 01), I think it says 01 or 001, can't remember without going back to it, but anyway, I'm suspecting that only 1 line of code was loaded? Because I BL or even a B @>3000 was unsuccessful.

 

                               HOME AUTOMATION

 

                             CELEBRITY ROASTS
                                   featuring...
                                    GDMike

 

I really look up to GDMike's programs, they're so brave!

...Even when threatened... They refuse to RUN.

 

 

Edited January 24, 2022 by HOME AUTOMATION

[GDMike]

Well. I have to draw a closure point and balance out if solving the problem actually gets me further or just fixes the problem at hand.

I'm sure with a bit more work it would have worked, probably something simple, but I was supposed to be doing Forth stuff this year and I really think it's more important to get back into forth. I know, I can hear you from here.... maybe coming back to it later..

Now fix my dog

Edited January 24, 2022 by GDMike

[HOME AUTOMATION]

Pyle, how many times have I told you, "There are no deserters in my outfit"!

[HOME AUTOMATION]

I actually did this last night, but thought I'd give you some time to respond...

 

...As I somewhat suspected, LOADER, reads the DF80, object file, 1 line at a time...

 

 

...building the program a few instructions at a time, before  reading the next line and doing the same again, until all lines have been processed...

 

 

Oh... unless your assembled code begins with an executable instruction, intended to be your program's entry point, B@>3000 probably wont get you where you want to go reliably!

 

It shouldn't be to difficult to ascertain the DEFed entry address though, or perhaps you could use ENDRUN, so the loader will run the code immediately after loading.

[GDMike]

4 minutes ago, HOME AUTOMATION said:

It shouldn't be to difficult to ascertain the DEFed entry address though, or perhaps you could use ENDRUN, so the loader will run the code immediately after loading

Yeah, well I wanted to just store the code into SAMs and use it when needed, but like you, a clever person, said, then you don't need SAMs and just run the code at will. So.. I guess, I'm more comfortable in a hammock..as in, I don't know what to think.  Desertion is never an option, but postponement of the idea may be what I need for now.

Edited January 24, 2022 by GDMike

[GDMike]

BTW..SNE and SNP were blockbuster hits! I use SNP Everytime for keeping my programming history journal. Be easy..

[HOME AUTOMATION]

17 minutes ago, GDMike said:

Now fix my dog

Never,

 

...I'm afraid that I love puppies a little too much!?

[+TheBF]

1 hour ago, HOME AUTOMATION said:

I actually did this last night, but thought I'd give you some time to respond...

 

...As I somewhat suspected, LOADER, reads the DF80, object file, 1 line at a time...

 

 

...building the program a few instructions at a time, before  reading the next line and doing the same again, until all lines have been processed...

 

 

Oh... unless your assembled code begins with an executable instruction, intended to be your program's entry point, B@>3000 probably wont get you where you want to go reliably!

 

It shouldn't be to difficult to ascertain the DEFed entry address though, or perhaps you could use ENDRUN, so the loader will run the code immediately after loading.

He's not making a program per-se just a block of sub-routines that live in memory at >3000. 

So his main program just needs to know the entry points for all the sub-routines.