Supernotes

[+Lee Stewart]

9 hours ago, GDMike said:

I start writing my new words I'm just worried about how much RAM I'm going to have so I've got to figure out how to use HERE. But it doesn't look difficult to create FREE.

 

The dictionary grows up from HERE toward the stack, while the stack grows down from the base of the stack at >FFA0. The current top of stack can be retrieved with SP@ . You are correct that it is a fairly simple matter to compose a word to report the amount of free memory between HERE and SP@ . Such a word is defined in the spoiler below:

Spoiler

: FREE SP@ HERE - ;

 

 

As you surely know, the stack is volatile in that it rises and falls as values are pushed and popped to/from it. The dictionary, however, grows inexorably larger as words are added. Memory can only be recovered by using FORGET .

 

...lee

[GDMike]

Ahh..thx lee I also figured out how to flush screens to my backup disk.

This clears the super cart too

Edited October 8, 2020 by GDMike

[GDMike]

Ok, now im stoked. I didn't know I could do BSAVE more than once on my final disk.

I've setup a source disk and after I've gotten a few things ironed out I did a BSAVE to my disk 1 forth boot disk..

 

And I've been loading screens and never compiling them! Omg

well, learning isn't always roses.

Edited October 8, 2020 by GDMike

[apersson850]

And then there's a return stack somewhere too, right?

[+Lee Stewart]

3 hours ago, apersson850 said:

And then there's a return stack somewhere too, right?

 

Indeed there is. It grows down from high low-expansion RAM (>3FFE) toward the Assembler support code, with last bit of code (flag indicating user ISR activity) at >3CD8—about 800 bytes from >3CDA to the return stack.

 

...lee

[+TheBF]

10 hours ago, GDMike said:

Ahh..thx lee I also figured out how to flush screens to my backup disk.

This clears the super cart too

Any particular reason you are only clearing part of the supercart and leaving the top end as is?

It is >2000 bytes.

 

[apersson850]

Note that this post is a sidetrack from the main subject.

But I just thought about how many different ways there are to manage memory.

Here in Forth we have the data stack in high 24 K memory and code storage in low 24 K memory. Then we have the return stack in high 8 K memory.

 

If you look at the p-system (Pascal), it uses only one stack, for both data and return addresses. It's in the same place as for Forth, high 24 K RAM.

At the low end of the 24 K memory is the heap, which is an area used for dynamically created variables and memory locked code.

In between is the secondary code pool, where code that can be relocated, even after loading it, is placed. Normal p-code is relocatable any number of times. When requesting memory from the heap, or trying to push data to the stack, the system will create a fault if the request can't be granted. Then a memory manager is called, which investigates if moving the code in one direction can create enough available memory in the other direction.

If the code is segmented, then any segments that aren't called at the moment can be removed from memory, to release more memory for other purposes. If the removed code is later needed again, it will be reloaded from disk.

 

Since p-code is a byte-code, it can also run from VDP RAM. That's where the primary code pool is located, to avoid code competing with the heap and stack for memory. It's only if the primary code pool is full, or if code that has to be memory locked (like code containing assembly instructions), that code is loaded to the secondary code pool in expansion RAM.

 

The heap allows for un-synchronized allocations and releases of data. This means that free holes can be created inside the heap. They are also managed and can be re-used, also automatically.

 

All this is automatic within the p-system, which is yet another reason for why it's not as fast as Forth. But it's very memory efficient.

 

The fact that the p-system can combine the data and return stacks is to a large extent due to that the main language, Pascal, works with local data associated with each procedure/function. When a procedure is called, an activation record, with space for all local variables, is allocated on the stack. This record lives as long as the procedure is called, which means that also pushing the return address (and some other data, in something called a Mark stack control word, MSCW) at the same time, to the same stack, makes sense.

 

 

[+TheBF]

 

25 minutes ago, apersson850 said:

Note that this post is a sidetrack from the main subject.

But I just thought about how many different ways there are to manage memory.

Here in Forth we have the data stack in high 24 K memory and code storage in low 24 K memory. Then we have the return stack in high 8 K memory.

And to your first point TI-Forth is but one example.

I chose to put the data stack and the return stack in high memory and manage lower 8K as a heap+SAMS data heap.  

Interesting to note that unless one is doing deep recursion the Forth virtual machine runs quite nicely with a 20 item data stack and return stack.

This is because the programmer is doing all the management manually.     Forth is really a very clever macro-assembler/interpreter combination.

 

The P-Code system punches way above it's weight as an O/S on the TI-99.  The features you describe are not found in any other system on the 99 to my knowledge.

A command line interpreter would be a nice addition.

[GDMike]

1 hour ago, TheBF said:

Any particular reason you are only clearing part of the supercart and leaving the top end as is?

It is >2000 bytes.

 

 

8192...duh....I'm glad you said something.. 

I would have noticed though at some point when I DBL checked 7FFF. I would be like, what????

Gotta keep an eye on me...TRUST nothing, but verify!

 

My calculator said 1F40 is 8k.

 

ERASE RESIDENT
( addr n --- )
Clear n bytes of memory to zero starting at addr.

Edited October 8, 2020 by GDMike
Ahhhhhhhhhhhh

[apersson850]

In a way your calculator is correct. Hex 1F40 is really 8000 decimal, but 8 kilobytes amounts to 8192 bytes. Which is hex 2000.

 

The p-system was designed to provide portable source code (a big issue before things like Windows inhabitate a lot of machines out there) and run in small memory (a big issue when hardly any reasonably priced computer had more than 64 K RAM).

Portability we don't have much use for today, but running in small memories is still needed to run the p-system on the TI 99/4A.

[GDMike]

Could I use the SAMs code from TF in TIForth to get my Sam's to work like it does in TF?

Hmm.. I may key in it and see.

[+Lee Stewart]

1 hour ago, GDMike said:

My calculator said 1F40 is 8k

Well—It is. 8000₁₀ = 1F40₁₆. Officially, 8 kB no longer means 8 x 2¹⁰ bytes (8192₁₀ = 2000₁₆), as it once did. That notation has been changed to 8 KiB. “KiB” is short for “kibibyte”, which is short for “kilo binary byte”.

 

...lee

[GDMike]

Forth is so much easier to work with sometimes.

Here I'm just setting up the menu.

 

Edited October 8, 2020 by GDMike

[+Lee Stewart]

3 hours ago, GDMike said:

Could I use the SAMs code from TF in TIForth to get my Sam's to work like it does in TF?

 

The code for TurboForth is in TMS9900 ALC as is the similar code for fbForth 2.0. I would use fbForth 2.0’s code because the Forth-system-register numbers are the same as used by TI Forth. If using the Forth Assembler, you will need to translate the TMS9900 ALC to Forth ALC. Also, you cannot use low-expansion RAM for paging because you would step on the system support code and the Forth block buffers. For that, you should use the high end of high-expansion RAM and relocate S0 (Parameter Stack Base) and TIB (Text Input Buffer), which is effected in fbForth 2.0 with S0&TIB! . Before all of this, you need words to turn SAMS on and off. I do not think you can initialize SAMS to anything different from the default mapping once TI Forth is booted (page numbers to corresponding 4-KiB-RAM boundaries, viz., page 2:>2000, ..., page >F:>F000).

 

Of course, the above scenario can also be implemented in high-level Forth code. I will put together a set of words for TI Forth that will manage SAMS as described above, first in Forth and then in Forth Assembler.

 

I have included the ALC and comments for fbForth 2.0’s >MAP in the spoiler for your delectation:

Spoiler

;[*** >MAP ***       ( bank addr --- )
* ...originally ported from TurboForth code courtesy of Mark Wills
* ...modified to handle 128 KiB -- 16 MiB
* 
* Address, addr, should be a valid address on a 4K boundary (e.g., >2000,
* >3000, >A000, >B000, >C000, >D000, >E000 or >F000). Bank should be a number
* between 0 and >0FFF. >0FFF is the top page of 4096 possible with 16 MiB SAMS.
*
* Important Notes: 
* 
* When a SAMS memory expansion card is fitted, the 32K of CPU RAM is actually
* taken from the SAMS memory. At startup fbForth reserves the following banks
* of SAMS memory for "standard" 32K RAM, which are the default startup banks:
* 
*        Bank   Description
*        -----  -----------
*        >0002  4K @ >2000
*        >0003  4K @ >3000
*        >000A  4K @ >A000
*        >000B  4K @ >B000
*        >000C  4K @ >C000
*        >000D  4K @ >D000
*        >000E  4K @ >E000
*        >000F  4K @ >F000
* 
* fbForth reserves lower RAM (>2000..>3FFF) for 4 block buffers, low-level
* support, system variables and the return stack, therefore extreme care
* should be taken when paging banks >0002 and >0003 out of >2000 and >3000,
* respectively.  The same care should be taken with upper RAM when paging
* banks >000A and >000F out of >A000 (start of User Dictionary) and >F000
* (TIB and base of parameter stack).
*
* Because the RAM portion of the dictionary grows up from >A030 and the
* parameter stack grows down from >FFA0, extreme care must be taken mapping
* SAMS memory.  It is probably advisable to limit SAMS mapping to one or two
* 4KiBb window(s) at >E000 and/or >F000.  If >E000 is used, the stack is
* limited to 2000 cells, which is probably sufficient for most programming.
*
* S0&TIB! can be used to change S0 and TIB (same address) to just below the
* the lower SAMS paging area. This will also restore the TIB and copy S0 and
* TIB to the default values table so that the settings will survive a COLD
* start. If you were to decide to use >E000 and >F000 for 2 SAMS blocks, you
* would type 
*             >D000 S0&TIB!
* to set S0 and TIB to >DFA0 and to copy the old TIB contents to the new.
*
* Previous builds of fbForth assumed a 1 MiB SAMS memory card, but since build
* 13, 128 KiB -- 16 MiB SAMS cards are allowed.
* 
* If a SAMS card is present, >MAP maps memory bank "bank" to address "addr"
*
*        DATA SOUN_N
* TOMP_N .name_field 4, '>MAP '
* TOMAP  DATA $+2
*        BL   @BLF2A
*        DATA _TOMAP->6000+BANK2

_TOMAP MOV  *SP+,R1           get address
       MOV  *SP+,R2           get bank
       ANDI R1,>F000          set to 4KiB boundary
       SRL  R1,11             divide by 2048
       AI   R1,>4000          convert to SAMS register address
       MOV  @SAMSFL,R0        get SAMS flag to R0
       INV  R0                invert it for mask
       SZC  R0,R2             mask off pages too high
       SWPB R2                reverse byte order for writing to SAMS register
       LI   CRU,>1E00         CRU address of SAMS
       SBO  0                 enable SAMS registers
       MOV  R2,*R1            poke SAMS register
       SBZ  0                 disable SAMS registers
       B    @RTNEXT           back to inner interpreter
;]

 

 

...lee

[GDMike]

Rasberry pi is back up! Whohoo..

And all my files from Sept are intact.

Not shown is my little fan I added in. Very cool ☺️

Edited October 8, 2020 by GDMike

[GDMike]

;[*** >MAP ***       ( bank
addr --- )

Ahh.. ok

I'll look at that.

[GDMike]

In the meantime..I found this @ theBF

That the msp430 and

http://www.camelforth.com/page.php?8

Edited October 8, 2020 by GDMike

[+TheBF]

24 minutes ago, GDMike said:

In the meantime..I found this @ theBF

That the msp430 and

http://www.camelforth.com/page.php?8

Yes I used Brad's Camel Forth for the high level parts of Camel99 Forth, thus the name.

Dr. Brad Rodriguez is someone I met years ago at a Forth conference. He's up here in the great white north too.

 

He used to use Forth a great deal but I think to earn a better living he has move to the dark side of the *schwartz.  

 

Funny thing about Camel Forth, He wrote the MSP430 source code in Assembler like FbForth and TF are but the comments are all Forth code.

So I just copied the comments and fed them (with a few magic incantations) to my cross-compiler and voila!  Camel99 Forth.

(I had to write all the primitives in Assembler first however oh and I guess the cross-compiler too but the last part was easy.)

 

And now my life will never be the same...

 

*From Spaceballs, the movie

[GDMike]

 

Ok, I've decided to scrap my SNP assembly program.

Due to the

SAMs Function doesn't work yet

Filing doesn't work yet

Sound doesn't work yet

And load time is approx what Forth is.

 TI FORTH, uses the EA GROM

And I didn't know about BSAVE!

I've pretty much mastered video!

and Why not use forth?

Last year I started off with Turboforth, but couldn't access supercart.

I do have work to do. 

I do have some questions, and 

One question is this.

Since I'm more used to turbo forth and I've gotten used to how it works, I'm switching over to TI forth and I noticed TI Forth so far won't allow me to switch drives easily.

I use the DR0 and DR1 words, but notice that when applying a flush, the default of DR0 takes hold and flushes to drive 1 instead of drive 2.

Because I really want to be mapped to my TIPI, unless I force my DSK1 drive?

Anyway, does anyone know how I can actively default to another drive?

Lee, I May ask to lift some FB words if you don't mind for my project??

And one rt off hand, ok two,

1. SAMs stuff.

2. but I need an editor, the built-in editor of TI FORTH doesn't auto repeat.

I'll probably do ok building my own external editor for SNP, since there are SO many options available.. it's just nailing one particular method down.

Plus I'll enjoy the learning curve.. and lastly, I would enjoy TIFORTH hosting this project and maybe encourage others.

 

 

 

 

 

 

Edited October 9, 2020 by GDMike

[+Lee Stewart]

4 hours ago, GDMike said:

One question is this.

Since I'm more used to turbo forth and I've gotten used to how it works, I'm switching over to TI forth and I noticed TI Forth so far won't allow me to switch drives easily.

I use the DR0 and DR1 words, but notice that when applying a flush, the default of DR0 takes hold and flushes to drive 1 instead of drive 2.

Because I really want to be mapped to my TIPI, unless I force my DSK1 drive?

Anyway, does anyone know how I can actively default to another drive?

 

I can help you with this tomorrow. It might be easier using fbForth 1.0, which is virtually the same as TI Forth, but with blocks files instead of direct sector access.

 

4 hours ago, GDMike said:

Lee, I May ask to lift some FB words if you don't mind for my project??

 

No problem.

 

4 hours ago, GDMike said:

2. but I need an editor, the built-in editor of TI FORTH doesn't auto repeat.

 

I believe I fixed that for the 40-column editor a long, long time ago. If I did, I will post it. I also have disk images for fast loads of the 64-column editor.

 

...lee

[+Lee Stewart]

11 hours ago, GDMike said:

2. but I need an editor, the built-in editor of TI FORTH doesn't auto repeat.

 

6 hours ago, Lee Stewart said:

I believe I fixed that for the 40-column editor a long, long time ago. If I did, I will post it. I also have disk images for fast loads of the 64-column editor.

 

I did fix the 40-column editor’s lack of auto-repeating keystrokes, but it appears that I did not fix it until fbForth 1.0—at least, I have not yet found any of my TI Forth system disks with the fix. I should think it easy enough to port from fbForth 1.0. Again, though, I would take a serious look at fbForth 1.0. You will not need to worry about sector-level access to blocks/screens. which is a problem with TIPI.

 

...lee

[GDMike]

7 hours ago, Lee Stewart said:

 

I can help you with this tomorrow. It might be easier using fbForth 1.0, which is virtually the same as TI Forth, but with blocks files instead of direct sector access.

 

 

No problem.

 

 

I believe I fixed that for the 40-column editor a long, long time ago. If I did, I will post it. I also have disk images for fast loads of the 64-column editor.

 

...lee

I'm only using the 40 col editor. Thx

[GDMike]

 It might be easier using fbForth 1.0, which is..

 

UPDATE: I went ahead and dl'd the

1.0 ver. And the manual.

 

did FB 1 have the SAMs already added in?

if so.. probably better to use it. Yes

 

 

Edited October 9, 2020 by GDMike

[GDMike]

Update: I used TDIR and moved them from the laptop to my gotek, to floppy.

Done!

 

Darn. The download files with the directories, FBforth100 and relative files called FBforth all give me a illegal tags

Edited October 9, 2020 by GDMike

[+Lee Stewart]

45 minutes ago, GDMike said:

The download files with the directories, FBforth100 and relative files called FBforth all give me a illegal tags

 

I don’t know what that means. What exactly are you trying to do with the files? What directories? What exactly did you download?

 

...lee