fbForth fbForth—TI Forth with File-based Block I/O [Post #1 UPDATED: 06/09/2023]

[+jedimatt42]

So far so good. No complaints when the FBLOCKS and font files are totally absent. The font file controls work well, as described. My project only needed a tweak to refresh the FBLOCK words I've BSAVE'ed into my own blocks file. But of course, that is to be expected with BSAVE.

 

 

I'll try real iron tomorrow. -M@

[+Lee Stewart]

I just fixed a bug that screws up multi-line terminal entry of DATA[ ... ]DATA .

 

I have also jockeyed ALC around such that I believe I have enough room in all banks to add an 80-column menu option on the powerup, rainbow screen. I will try to have a binary with the bug fix and the additional menu option by late tonight or early tomorrow. It will be v2.0:7...or...do you think it is time to call it v2.1?

 

...lee

[+jedimatt42]

If you call it 2.1, I'll have to update the label on my cart. Which would let me attempt to follow Omega's instructions on cartridge label crafting. ( I have the supplies, just itching for an excuse )

 

With the font and new resident words, it could be time for a v2.1... At work, we version things like this:

major.minor.patch

 

major = incompatible or major tada additions

minor = additional functionality

patch = bug-fixes

 

So by the logic, you'd be at 5.1.1 by now. Not so much from incompatible, but mostly 'tada' additions.

[+Lee Stewart]

I hadn't thought of the label investment. Jim (@Ksarul) probably has a good many more than I do. BTW, here is my fbForth 2.0 label.

 

...lee

[+Lee Stewart]

I decided to call this next build, v2.0:7. I will attach it to post #1 in a few minutes. I will include an updated FBLOCKS file that has the binaries for the last three menu choices updated.

 

This build has the additional 80-column startup option. Again, let me know if you find any bugs.

 

...lee

[+Lee Stewart]

fbForth 2.0:7 and the latest FBLOCKS file are posted in post #1.

 

Additional words included in the resident dictionary are

 

DATA[ ]DATA DCHAR SPDCHAR CODE: ;CODE

 

...lee

[+jedimatt42]

I'm having trouble with BLOAD of stuff I BSAVE with 2.0:7

 

In particular, I'm using the SCROLL words on FBLOCKS block 62...

So, I perform the following sequence with FBLOCKS in DSK1, and my work file at HDX1.FTI2B:

 

COLD

...

FORGET MENU

62 LOAD

USEBFL HDX1.FTI2B

' WRAP 17 BSAVE . (outputs 18, all fits in one block)

FORGET WRAP

17 BLOAD (goes out to lunch...)

 

or

 

17 CLOAD SCROLL (returns some garbage data to the screen.)

 

Have I forgotten how to do this? Or have I been doing this wrong and getting away with it? I believe I followed the same process when updating my BSAVE'ed blocks with 2.0:6 just the other day.

 

loading the assembly words ( 27 LOAD ) which turns around and 28 BLOAD works fine off the FBLOCKS file.

 

-M@

[+jedimatt42]

Oh, and FBLOCKS block 62 has a '61 CLOAD SPDCHAR' sequence, as well as FBLOCKS block 65 ( the TI Forth disk browser... )

 

I assume those are unnecessary now that the SPDCHAR word is resident in ROM.

 

-M@

[+Lee Stewart]

Unless you are designing an overlay system, you should probably use TASK as the reference point for BSAVE and BLOAD :

 

' TASK 17 BSAVE.

 

Also, you cannot CLOAD or LOAD a binary image saved with BSAVE .

 

I will get back to you with more information when I get home to my computer.

 

...lee

[+jedimatt42]

Thanks, I obviously forgot what I was doing.

 

I was not building an overlay, and should have been saving from TASK, as you say.

The CLOAD that I said returns garbage should never have worked. I recorded a mistake that seemed to work as long as the target word was already loaded.

 

-M@

[+Lee Stewart]

Oh, and FBLOCKS block 62 has a '61 CLOAD SPDCHAR' sequence, as well as FBLOCKS block 65 ( the TI Forth disk browser... )

 

I assume those are unnecessary now that the SPDCHAR word is resident in ROM.

 

-M@

 

Yes. They are unnecessary, but harmless, because they do not take up space in RAM. They are executed at LOAD time and only take up space on disk.

 

...lee

[+Lee Stewart]

As the result of a suggestion by @--- Ω --- in a PM conversation, I wrote a batch script to pack the four 8KiB fbForth 2.0 ROM binaries into inverted or normal (non-inverted) banks in a single 32KiB binary file that is then replicated as needed to fill any desired larger-sized binary up to 512KiB.

Usage: fbForthBinPack I|N 32|64|128|256|512

I = Inverted bank selection for 74LS379 Guidry/BLACK boards.

N = Normal bank selection for 74LS377/378 BLUE/RED boards.

Numeric parameter = Finished size of image file in KiB.

Example: fbForthBinPack N 512

The above will produce a 512KiB ROM image file for a BLUE/RED board with normal bank selection. The file will be named fbForth200_512N.bin. You can, of course, rename it to whatever you like.

You can download a ZIP file, which contains the four 8KiB binaries, the batch file and a readme file, from post #1. It is marked with .

...lee

[Omega-TI]

 

You can download a ZIP file, which contains the four 8KiB binaries, the batch file and a readme file, from post #1. It is marked with new9.png.

 

This works fantastically fast & easy. Now anyone with any type of cart out there can make an FbForth cartridge for themselves. This will also help with new releases and updates!

[+Lee Stewart]

In an effort to clean up the comments in my assembly language source code for fbForth 2.0 to make it publishable (read, “easier to follow than in its current state”), I am finding ALC that merits improvement in speed and/or footprint. I am about halfway through the resident dictionary piece that fits in bank 0 and, already, I have made substantive changes to the ALC for the following words, which have either increased speed or reduced footprint:

 

CREATE M+ M/ I 0BRANCH (OF) (LOOP) (+LOOP) EMIT8 SLA SRA SRC XOR C@ U< = < > MIN MAX

 

M* [ stack signature: ( n1 n2 --- d ) ] and M/ [ stack signature: ( d n --- rem quot ) ] are two words that I modified to increase speed at the expense of the footprint. They are mixed magnitude words that are referenced five and six times, respectively, by other words. Coding them in ALC cost me 36 bytes, but increased speed 2.7X and 3.7X, respectively. I think the tradeoff was worth it.

 

So far, the available space in the four banks is:

 

Bank Bytes

---- -----

0 68

1 38

2 102

3 22

 

Unless there are serious bugs found in v2.0:7, I think I will wait until I have finished cleaning up the code to post the next build. I just wanted to report my progress.

 

...lee

[+Lee Stewart]

I was nearly done with the ALC cleanup when I realized that I could probably fix the too-many-labels problem that had forced me to compile my Floating Point Math Library (FPL) separately from the rest of fbForth 2.0. Some of you, who have been with me for most of this thread, will recall that I had hit upon a scheme (around post #644, 2 years ago!) for splitting word headers from word bodies into a doubly linked list in bank 2. My implementation used two new labels per resident word and an extra PFA label for all resident words. This resulted in somewhat less than three new labels per word because most words in the resident dictionary did not have labels for PFAs. Pretty much, the only PFA labels required in ALC before the split were those words that started with a BEGIN ... AGAIN , BEGIN ... UNTIL or BEGIN ... WHILE ... REPEAT loop. For 482 resident words, that amounts to about 1446 new labels!

 

Quite awhile ago, I eliminated the CFA-pointer label because, though I had anticipated doing so, I never actually used it. That reduced the label count by 482. Next, I eliminated all but a handful of the PFA labels and replaced references to them with <CFA> + 2—tedious, but easy enough. While doing this, I began to understand that, not only could I replace another 482 labels with a simple calculation (this time, <label> - 6), I could also eliminate two pointers per word and revert to a singly linked list with minor adjustments to the dictionary search words, which would free up 1928 bytes in bank 2!

 

The upshot of all of this is that

1. I have successfully assembled the FPL with the rest of fbForth 2.0 so that the build process is no longer disjointed;
2. I am reverting to a singly linked header list in bank 2; and
3. I am modifying the dictionary-search words to accommodate (2).

It shouldn't be long now for fbForth 2.0:8.

 

...lee

[+Lee Stewart]

After a couple of missteps during the modification described in my last post, everything seems to be working.

 

I had to move the two ASSEMBLER vocabulary words ( NEXT, ;ASM ) that are in the kernel to low RAM to make it easier to re-code the dictionary search routines. That only cost 44 bytes, making the available return stack space 1462 bytes.

 

After I move BSAVE out of bank 1 into bank 2, available bank space will be

Bank Bytes

---- -----

0 96

1 198

2 1890 !!

3 52

...lee

[+jedimatt42]

After a couple of missteps during the modification described in my last post, everything seems to be working.

 

I had to move the two ASSEMBLER vocabulary words ( NEXT, ;ASM ) that are in the kernel to low RAM to make it easier to re-code the dictionary search routines. That only cost 44 bytes, making the available return stack space 1462 bytes.

 

After I move BSAVE out of bank 1 into bank 2, available bank space will be

Bank Bytes

---- -----

0 96

1 198

2 1890 !!

3 52

...lee

 

 

That is impressive. Do you have plans for that space lined up yet?

 

-M@

[+Lee Stewart]

That is impressive. Do you have plans for that space lined up yet?

-M@

 

Not yet. Just musings about speech and sound so far.

 

...lee

[+Lee Stewart]

 

 

That is impressive. Do you have plans for that space lined up yet?

 

-M@

 

...maybe WRAP , PANEL and SCROLL ...

 

...lee

[+Lee Stewart]

Well...I got WRAP , PANEL and SCROLL working in the kernel. I managed to shave about 100 bytes from its footprint, as loaded from FBLOCKS, by combining the ALC for left and right scrolling because most of it was duplicate code. Up and down scrolling are still separate routines. Available bank space is now

 

Bank Bytes

---- -----

0 80

1 190

2 1500

3 52

 

...lee

[+jedimatt42]

-Sounds- like there is still room for some words on speech and sound.

 

-M@

[+jedimatt42]

Slightly off topic, you'll have to forgive me, but:

 

Happy Star Wars Day! On this, May the Forth.

 

-M@

[+Lee Stewart]

I am putting in a lot of time on getting speech into the kernel. In the process, I realized I have quite a few instances of “LIMI 2” in the kernel code that would screw up a user ISR were those routines called by that ISR. They all need to be contingent on the inactivity of a user ISR. I think I have figured out a way to do it without too much additional code—but, I certainly must do it!

 

Getting there—slowly.

 

...lee

[+Vorticon]

Nice work Lee

[+Lee Stewart]

I have speech working with the fbForth 2.0 ISR. The binaries are attached as beta versions for testing. The cartridge bootup shows the current build as '+'. Please beat the hell out of it and report any bugs or undesirable behavior:

 

fbForth2.0-BETA_20160511.zip

 

The words TALKING? , SAY and STREAM work the same as in TurboForth. You can use DATA[ ... ]DATA before SAY and STREAM to give them the address and cell-count they need. So far, I have only tested SAY and the installation of a user ISR.

 

I will test the other words and look at implementing sound while y'all test this beta build.

 

...lee