Jump to content
GDMike

Foxit - in progress

Recommended Posts

Yes, and after pressing a key to clear the screen my default charset is activated.

I'm trying to BSave it, but having issues. Mark said create another block file and save the dictionary to it, but I don't know how to save out or copy out the dictionary to another block file.. unless I just duplicate my original block file.. which o also tried and the BSave only grabbed a portion of my original block file (it's all in Memory), and I ticked the first word in the dictionary, for the CFA, and used link. 

So I'm missing the part I suppose, to copy the dictionary out.. but I thought it'd work regardless and just write it to the current block file.

And of course it's snowing here and I forgot my forth book at home because I was trying to get everything in order before leaving the house for work...

Share this post


Link to post
Share on other sites

I'm also defining words in SAMs banks. So I don't know if that has anything to do with it either.

Edited by GDMike

Share this post


Link to post
Share on other sites

Yeah, BSAVE ain't gonna work if you're using SAMS banks, sorry!

  • Thanks 1

Share this post


Link to post
Share on other sites
39 minutes ago, Willsy said:

Yeah, BSAVE ain't gonna work if you're using SAMS banks, sorry!

The good news is that saving a 4K sams block to disk blocks should be pretty simple no?

 

I don't know where TF's block buffers live so this could bomb badly

\ UNTESTED!
$400 CONSTANT 1K
$3000 CONSTANT WINDOW

: SAMS>BLOCK ( bank# block# --)
              SWAP  WINDOW MAP
             4 0 DO
                   WINDOW 1K I * + ( -- addr1 )
                   I BLOCK         ( -- addr1 addr2 )
                   1K CMOVE
              LOOP ; 

 

  • Like 1

Share this post


Link to post
Share on other sites
13 minutes ago, TheBF said:

I don't know where TF's block buffers live so this could bomb badly

 

TurboForth’s block buffers live in VRAM.

 

...lee

  • Like 1

Share this post


Link to post
Share on other sites
2 minutes ago, Lee Stewart said:

 

TurboForth’s block buffers live in VRAM.

 

...lee

So that's a bit of a wrinkle but not too hard to overcome I think. It's might better for this that my system since I have both in Low Ram.

In Camel99 you would have to put the SAMS window at >2000. The 3 block buffers start at:  >3FFF  >404 3 * -   ( -- >33F3)

  • Like 1

Share this post


Link to post
Share on other sites

Yes, it's doable. A script to do multiple BSAVES for each bank would be possible.

  • Like 2

Share this post


Link to post
Share on other sites

Thinking about it some more, TF has rich block buffer commands. It would be quite simple to copy 4K of SAMS memory to consecutive block buffers, then use DIRTY (IIRC) to tell TF to flush them when FLUSH is executed. SETBLK would be used to associate the block buffers in memory with physical blocks on disk.

 

See http://turboforth.net/lang_ref/words_by_glossary_category.asp?ID=19

 

I'll knock something together tonight.

Edited by Willsy
  • Like 2

Share this post


Link to post
Share on other sites

I hope it's something I can grasp. Hehe...

I'm wondering, would the BSave load into VRAM or could it partition into SAMS.. because, I'm afraid of running outta VRAM and MAIN CPU ram to continue coding...or Maybe I'm missing something.. not unusual..

Share this post


Link to post
Share on other sites
47 minutes ago, GDMike said:

I hope it's something I can grasp. Hehe...

I'm wondering, would the BSave load into VRAM or could it partition into SAMS.. because, I'm afraid of running outta VRAM and MAIN CPU ram to continue coding...or Maybe I'm missing something.. not unusual..

What is the project you are making that uses all of CPU RAM and VDP RAM?

  • Like 1

Share this post


Link to post
Share on other sites
58 minutes ago, TheBF said:

What is the project you are making that uses all of CPU RAM and VDP RAM?

I'm still looking at Foxit database. 

For the program to be friendly and useable, it's wanting to grow fast. User Data isn't the issue, it's the program and the interaction a user has with it, and all that code that goes along.

I can make it work in assembly, as I found a way load source files prior to loading in the actual program and pushing that all over to SAM and I might continue with that this Evening, but I've been playing with forth this week because I miss it and it gave me time to think about Foxit.

But, I'll be back on TF one day. I don't like starting something without finishing. Lol

 

  • Like 2

Share this post


Link to post
Share on other sites

Im stuck rt now between TF & Assembly with Foxit..so I'm going to include a Forth tutorial section here while trying to complete Foxit.

So, each weekend, if you feel the urge, just DROP a new forth word with example here and I'm sure someone other than me could benefit from the excersize....

 

My first example is. Not so much a word, but a starting place.

 

STACK 

 

Forth interacts between you and Forth by communicating through the STACK.

If I press the number "6" on the keyboard and press enter I get a "1" and "ok".  Like, -->   1 ok

 

Meaning, I've got 1 number on the stack.

I'm not sure how many numbers can be placed on the stack, is it 8? I'm not sure...

But that is my starter 

 

I've also got an idea dropped to me by @AUTOMATION for "importing" a DF80 object file so I can stuff object code on the fly into SAMS banks.. this is a game changer if it works. I'll be playing with it this weekend.

thank you for that. Because I was 10 seconds away from doing this in forth since SAMs can run prior to compiling words unlike assembly, and you can continue coding and incrementing SAMs banks as you need.

whereas assembly needs all code assembled prior to SAMs mapper launching.

so I'm hoping I can pull in object code that's already assembled. Push it to a SAMs bank and my routine, already aware of what the code will be and where to BL or B to with a RT or a known address to Branch out to.

to be tested though, so fingers crossed.

 

I also did a test in classic 99. I setup SAMs mapper and I placed >4142 into address >3000  SAMS bank >FE00

And I rebooted. 

I had another piece of code that set SAMs bank >FE00 address >3000

That reads the first word and places that onto the screen..I got garbage.

 

I ran the same process on real hardware and I got my "AB" on the screen from the last process, as I expected. 

I was able to push the same data to >6000 

Rebooted and the data was retained.

 

Classic 99 retains what I placed into bank >6000->7FFF as I tested that.. and that is what gave me the idea that maybe I can write 2 or 3 routines and push them into SAMS and reboot and launch Foxit and I'll have my SAMs banks loaded from the previous push by using the EA cart, load file.

Anyway, that was going to be my other option..

 

 

 

Edited by GDMike

Share this post


Link to post
Share on other sites

You can definitely do this in TF, and in sure in fbForth and Camel99 too.

 

There is an object loader for TF that I wrote years back that will load editor assembler option 3 files (tagged object code). And DEFs in your assembly source are defined as forth words so you can call your assembly code easily from your forth code.

 

Loading it to a Sams bank should be as simple as mapping in the bank, then set the variable H to 3000 hex (i.e $3000 H !) then run the loader. Voila, your code is in SAMS.

 

You would then have a 'wrapper' word in normal 32 memory that would call your assembly routines for you. They would just map the correct bank in to low memory and call the word. Very simple. I could make a video showing you how to do it. Procedure would be somewhat similar for fbForth too, I think.

 

There's also the use of the word CODE: see 

http://turboforth.net/lang_ref/view_word.asp?ID=145

There is a utility that will take Forth Assembly code and convert it to CODE for you. It's on one of the disks.

 

A number of ways to skin the cat.

 

Have you taken a look at TI Base? That's what you want to aim for. It has its own scripting language built in for processing records. By using Forth you wouldn't need to implement that side of it at all. Forth *is* the scripting language!

 

 

  • Like 3
  • Thanks 1

Share this post


Link to post
Share on other sites
1 hour ago, GDMike said:

Forth interacts between you and Forth by communicating through the STACK.

If I press the number "6" on the keyboard and press enter I get a "1" and "ok".  Like, -->   1 ok

 

The response from TurboForth and fbForth is

  ok:1

 

1 hour ago, GDMike said:

I also did a test in classic 99. I setup SAMs mapper and I placed >4142 into address >3000  SAMS bank >FE00.

 

First off, I am sure you mean SAMS bank >00FE. Bank >FE00 would require a 256 MiB SAMS! >FE00 is what you write to the SAMS register to swap in SAMS bank >00FE.

 

At the moment, you cannot use TurboForth’s >MAP for SAMS in Classic99 because it will only work on SAMS ≤ 1 MiB due to its copying the SAMS page# to both bytes. Classic99 has 32 MiB SAMS, so writing >FEFE to a SAMS register selects SAMS page >7EFE.

 

2 hours ago, GDMike said:

And I rebooted.    I had another piece of code that set SAMs bank >FE00 address >3000.   That reads the first word and places that onto the screen....I got garbage.

 

I ran the same process on real hardware and I got my "AB" on the screen from the last process, as I expected.   I was able to push the same data to >6000.   Rebooted and the data was retained.

 

Classic 99 retains what I placed into bank >6000->7FFF as I tested that... and that is what gave me the idea that maybe I can write 2 or 3 routines and push them into SAMS and reboot and launch Foxit and I'll have my SAMs banks loaded from the previous push by using the EA cart, load file.   Anyway, that was going to be my other option.

 

Yeah—You really should not rely on the survival of any code upon a reboot.

 

...lee

  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, GDMike said:

Im stuck rt now between TF & Assembly with Foxit..so I'm going to include a Forth tutorial section here while trying to complete Foxit.

So, each weekend, if you feel the urge, just DROP a new forth word with example here and I'm sure someone other than me could benefit from the excersize....

 

My first example is. Not so much a word, but a starting place.

 

STACK 

 

Forth interacts between you and Forth by communicating through the STACK.

If I press the number "6" on the keyboard and press enter I get a "1" and "ok".  Like, -->   1 ok

 

Meaning, I've got 1 number on the stack.

I'm not sure how many numbers can be placed on the stack, is it 8? I'm not sure...

With Forth you would test that at the command line. :)

This is a real thing with Forth. If you don't know. Ask the machine. It doesn't lie. 

 

Manually or like this:

: BLOWUP   0 DO  I DUP . LOOP ;
DECIMAL 10 BLOWUP  ABORT  

20 BLOWUP ABORT 

40 BLOWUP ABORT  

 

( ABORT resets all the stack to their default depths)

Try bigger numbers and when it blows up you have your answer. :)

  • Thanks 1

Share this post


Link to post
Share on other sites
1 hour ago, Lee Stewart said:

At the moment, you cannot use TurboForth’s >MAP for SAMS in Classic99 because it will only work on SAMS ≤ 1 MiB due to its copying the SAMS page# to both bytes. Classic99 has 32 MiB SAMS, so writing >FEFE to a SAMS register selects SAMS page >7EFE.

:-o 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...

; ; >MAP ( bank address -- )
; If a SAMS card is present, maps memory bank "bank" to address "address"
_sams   mov r12,r11                 ; save address of NEXT
        mov *stack+,r1              ; get address
        andi r1,>f000               ; set to 4k boundary
        srl r1,11                   ; divide by 2048
        ai r1,>4000                 ; convert to SAMS register address
        mov *stack+,r2              ; get bank
        andi r2,>ff                 ; mask off any crap                                 REMOVE
        mov r2,r0                   ; keep a copy                                       REMOVE
        sla r2,8                    ; move to high byte                                 REMOVE 
        xor r0,r2                   ; combine r0 & r2. Hi & lo bytes are now identical  REMOVE
        li r12,>1e00                ; cru address of SAMS
        sbo 0                       ; enable SAMS registers
        mov r2,*r1                  ; poke sams register
        sbz 0                       ; disable sams registers
        mov r11,r12                 ; restore address of NEXT
        b @retB0                    ; return to caller

 

Edited by Willsy
Added code
  • Like 2

Share this post


Link to post
Share on other sites

I was going to get cheeky and had this code from my system almost ported to TF and then found out that R12 contains NEXT...

That makes it pretty tough to do CRU I/O from Forth. :( 

 

\ SAMS CARD support for CAMEL99 Forth   May 2020  B Fox
\ MODs to run on TURBOFORTH
\
HERE
HEX
VARIABLE BANK#   \ current mapped bank

\ Legal window values: 2000,3000,A000,B000,C000,D000,E000,F000
3000 CONSTANT WINDOW

4000  WINDOW  0B >> +  CONSTANT SAMSREG  \ Data memory window in CPU RAM

!!OOPS!! CODE: R12! ( CRU -- )   C334  ;CODE \ *SP+ R12 MOV,

 : SAMSCARD  ( -- ) 1E00  R12! ;   \ select sams card

\ using machine code so we don't need the CRU Forth code
HEX
\ *set the CRU address in 'R12 before using these words*
  CODE: 0SBO  ( -- ) 1D00  ;CODE
  CODE: 0SBZ  ( -- ) 1E00  ;CODE
  CODE: 1SBO  ( -- ) 1D01  ;CODE
  CODE: 1SBZ  ( -- ) 1E01  ;CODE
  CODE: ><    ( aabb -- bbaa)  06D4   ;CODE \ swaps bytes of TOS

: SAMS-ON   ( -- ) SAMSCARD 1SBO ;  \ enable mapper
: SAMS-OFF  ( -- ) SAMSCARD 1SBZ ;  \ disable mapper

\ * SAMSINI sets card to "power-up" condition
: SAMSINI
       SAMSCARD          \ select SAMS card CRU address
       0SBO              \ turn card on
       0                 \ 1st value
       4000 20           \ register address, # SAMS regs
       OVER + SWAP ( -- 4100 4000)
       DO
           DUP I !       \ I is reg. address
           I @ OVER <> ABORT" SAMSINI err"
           0101 +        \ next value 0101 for real card, 0100 Classic99
       2 +LOOP
       0SBZ              \ turn off card
       DROP
;

\ Faster. Assume we know the CPU RAM address already
: MAPBANK ( bank# -- )   \ map a DATA page at WINDOW address
\      DUP BANK# @ <>
\      IF
          DUP BANK# !
          ><              \ swap bytes, bank# must be in left byte
          SAMSCARD 0SBO   \ turn on the card
        ( bank#) SAMSREG !
          0SBZ            \ turn off card
  \    THEN
;

SAMS-OFF
\ SAMSINI  ( Needed for real SAMS card. Not for Classic99)
SAMS-ON
CR .( SAMS card activated)

 

  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites
4 hours ago, GDMike said:

address >3000  SAMS bank >FE00

Oops. I meant bank 245.

I meant I just place this value into my R1 and pass it on to my mapper that handles the bank change. Thx lee

 

Share this post


Link to post
Share on other sites
2 hours ago, Lee Stewart said:

ok:1

Yes. I can't trust my memory for crap... what's in that soup that Lee is eating...

Share this post


Link to post
Share on other sites

By the way, @GDMike

There is also SAVE#5 and LOAD#5 built into the TF wordset. These allow you to save and load raw binary/machine code to ED/AS #5 disk (PROGRAM) files. You could store your SAMS banks as raw PROGRAM files and load them into the appropriate banks. Easy.

 

At some point I'll put a video together to show this - probably mid next week before I get around to it.

 

In the meantime, have a look at http://turboforth.net/lang_ref/words_by_glossary_category.asp?ID=20

 

  • Thanks 1

Share this post


Link to post
Share on other sites
3 minutes ago, Willsy said:

By the way, @GDMike

There is also SAVE#5 and LOAD#5 built into the TF wordset. These allow you to save and load raw binary/machine code to ED/AS #5 disk (PROGRAM) files. You could store your SAMS banks as raw PROGRAM files and load them into the appropriate banks. Easy.

 

At some point I'll put a video together to show this - probably mid next week before I get around to it.

 

In the meantime, have a look at http://turboforth.net/lang_ref/words_by_glossary_category.asp?ID=20

 

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.

 

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...