Lee Stewart
-
Posts
5,839 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by Lee Stewart
-
-
Maybe we should get Fred ( @F.G. Kaal ) to weigh in. I believe he had significant input to later versions of the DSR---maybe even wrote it?
...lee
-
1
-
-
One of my TODOs is to possibly change BRANCH and 0BRANCH to use absolute addresses (per @Willsy’s TurboForth) instead of an offset (per figFORTH/TI Forth/fbForth), but I really do not see the advantage except, possibly, at compile time, which does not seem that important. The difference at execution time is
MOV *IP,IP <---IP is a register
versus
A *IP,IP <---IP is a register
which take exactly the same amount of time, as far as I can tell. So, unless someone (@Willsy? @Tursi? @matthew180? @jedimatt42? @apersson850? @TheBF? ??) can show me a significant difference in execution time, I am inclined to leave sleeping dogs lie—the mod would be significant!
...lee
-
1
-
-
5 hours ago, Lee Stewart said:
Regarding booting up fbForth with its ISR disabled, I will have PLAY , STREAM , SAY check for a cleared ISR hook (>83C4) and, upon seeing it cleared, exit the routine immediately. Do you think I should include a message such as, “ISR not active!” or just fail quietly?
...lee
4 hours ago, TheBF said:There is some S/W principle I have read that is something like "Do the expected thing".
So I think a message is order since it will happen at run-time no?
You could save a couple of bytes with "ISR missing" or "Bad ISR" ??
I added a routine to check for the ISR hook and, if not there, to call the fbForth ERROR word with the proper error message number to print “ISR?” after the usual “ERROR ?” and abort.
While adding the new message, I took the opportunity to shorten many of the messages. Now, even after adding the ISR checking routine to bank#0 and the code to call it to 3 words in the same bank, there are 256 bytes free! I should add that the free-space increase is due not only to message size reduction but also to some other changes such as the redefinition of .S and shortening of a handful of words to use newly added words.
There is still a little work before release. Here is the current state of the TODO list: fbForth300_TODO.txt
...lee
-
3
-
-
Regarding booting up fbForth with its ISR disabled, I will have PLAY , STREAM , SAY check for a cleared ISR hook (>83C4) and, upon seeing it cleared, exit the routine immediately. Do you think I should include a message such as, “ISR not active!” or just fail quietly?
...lee
-
1 hour ago, dhe said:
Finally had some time to go back and play with a small bit of assembly.
I've been proof reading an english translation of the german assembly books kursi.
One of the comments he made in an example was that, we needed to get the MSB in to the LSB position for the next instruction. He mentioned instead of using SWPB, we would use SRL, while that does move the MSB>LSB, you loose the value of the LSB (unless it's already zero! 😃 ).
Using Steve's Cheat Sheet, I was able to quickly grab the instructions FMT, using xdt99's listing, I quickly got the number of clock cycles. - using a shift instruction cost double the clock cycles as swpb, tested by single stepping with Classic99.
That got me thinking about another example I've seen, which is setting a register to zero, by using XOR. That also costs four additional clock cycles over LI or two additional clock cycles compared to CLR. With CLR being the easy winner for expressing intent.
Of course, there can be many reasons for choosing one operation over another.
Regarding getting the MSB to the LSB, the point of using “SRL Rn,8” over “SWPB Rn” is usually to zero the MSB in the same instruction—saving instructions can outweigh speed. If you want to duplicate SWPB with a shift, “SRC Rn,8” will do nicely. Furthermore, if you want to test the result, the shift is the only way—SWPB does not affect the status register.
Regarding zeroing a register, CLR is, indeed, the clear (groan) winner—unless, for some reason, you need a comparison. Both XOR and LI affect the status register, whereas, CLR does not. LI also takes an additional 2 bytes over the other two, when dealing only with registers.
...lee
-
4
-
-
23 hours ago, adamantyr said:
Hmm... anyone have a GPLLNK they KNOW works with ROM banks?
I've gotten a few implementations over the years, but the one I am using doesn't appear to work; trying to issue an accept tone does nothing.
* Labels SUBSTK EQU >8373 * Subroutine stack pointer GETSTK EQU >166C * LDGADR EQU >60 * Load and execute GROM address entry point XTAB27 EQU >200E * Low-men XML table location 27 * Entry and Workspace GPLLNK DATA GLNKWS DATA GLINK1 RTNADR DATA XMLRTN GXMLAD DATA >176C * GROM address for 'XML >27' PUTSTK DATA >50 * Initialized to >50 where PUTSTK address is GLNKWS $->18 BSS 8 * Main routine GLINK1 LIMI 0 * Disable interrupts CLR @STATUS * Clear Status MOV @PUTSTK,@GPLWS+8 * Put PUTSTK address into R4 of GPLWS MOV *R14+,@GPLWS+12 * Put GPL routine in R6 of GPLWS LWPI GPLWS BL *R4 MOV @GXMLAD,@>8302(R4) INCT @SUBSTK B @LDGADR XMLRTN MOV @GETSTK,R4 BL *R4 LWPI GLNKWS RTWPPlease note that like it's RAM implementation, it's embedding it's workspace into itself; the BSS line is worthless since it can't write to it. Fortunately it doesn't get used.
I wish I could just skip it altogether but unfortunately GPL is the only (sane) way to allow for cassette use. Plus it wouldn't be terrible to have the error and accept tones readily available.
With your GPLLNK routine modified to use a writable workspace and storage locations (see @Gary from OPA post above), there are several Scratchpad RAM locations and one ROM location you can store XMLRTN for the return from GPL: >8300, >830E, >831C, >831E in Scratchpad RAM and >603E in ROM. The GROM0 addresses of the corresponding GPL XML instructions to place in the DATA directive at GXMLAD are >0376, >0EDA, >1675, >00E5, and >0131. Some of them have more than one GROM0 location, but I listed the first I found.
...lee
-
2
-
-
1 hour ago, Lee Stewart said:
I do like your BEGIN...WHILE...REPEAT instead of the DO...LOOP of fbForth because it looks shorter.
With a couple of changes (“ CELL - ” to “ 2- ” and “ ? ” to “ @ U. ”), the following code is, indeed, shorter—16 bytes less!:
: .S ( -- ) CR ." | " S0 @ BEGIN 2- SP@ OVER < WHILE DUP @ U. REPEAT DROP ;...lee
-
3
-
-
7 hours ago, TheBF said:
Over on comp.lang.forth sjack has been playing with Fig Forth and presented these little tools.
They seem to work perfectly on FbForth.
Edit. Fixed some case issues from the original text.
\ by: sjack - Wed, 3 Apr 2024 03:59 \ Put aside all my extensions and explored using FigForth core \ words only. Here are three of several things I found interesting: Fig-Forth 1.0.A ( Example #1, Stash data stack items) 2 CONSTANT CELL : XX S0 @ SP! ; : S0! S0 ! ; : !S0 TIB @ S0! ; : .S S0 @ BEGIN CELL - SP@ OVER < WHILE DUP ? REPEAT DROP ; ( some stack items.............) 1 2 3 4 5 .S 1 2 3 4 5 ( stash them...................) SP@ S0! ( use the stack................) 666 777 888 .S 666 777 888 ( restore stashed items........) XX !s0 .S 1 2 3 4 5 ( Example #2, Input counted string _directly_ into given storage area) : CREATE: <BUILDS DOES> ; : := DP @ SWAP DP ! 1 WORD DP ! ; CREATE: FOO 64 ALLOT ( storage area for counted string FOO) FOO := Hello Chuck! FOO COUNT CR TYPE Hello Chuck!
I didn't test this one.
** Be careful it will edit disk block 60 which you don't want to do **
( Example #3, Easily edit block screen without editor) 0 60 (LINE) DROP 1024 BLANKS 0 60 (LINE) EXPECT ( FOO BAR ) 1 60 (LINE) EXPECT : FOO ." foo " ; 2 60 (LINE) EXPECT : BAR ." bar " ; UPDATE FLUSH 60 LIST SCR # 60 0 ( FOO BAR ) 1 : FOO ." foo " ; 2 : BAR ." bar " ; 3 4#1 works, but XX is superfluous. SP! is already defined to clear the stack by storing the contents of S0 in the stack pointer. XX pushes the contents of S0 and SP! wipes it out, i.e., does not use it—so no harm done. Also, .S , though not in figFORTH, is defined in fbForth (from TI Forth) and I like it better because it shows the stack as unsigned numbers. I do like your BEGIN...WHILE...REPEAT instead of the DO...LOOP of fbForth because it looks shorter.
#2 certainly works as written and, I must say, I like it a lot. I think, though, that I would define := as
: := DUP 1 WORD C@ 1+ + =CELLS DP ! ;
to make the string only as long as necessary. Of course, neither form is protected against a second invocation of := for the same string with a length beyond the original.
#3 does not work properly for 2 reasons: (1) EXPECT must be executed (last word on the line) before typing the text following it, i.e., nothing happens until <enter> is tapped at the end of the line, so the typed string is ignored while EXPECT awaits input. (2) EXPECT stores 2 nulls after the string is entered.
...lee
-
1
-
-
1 hour ago, OLD CS1 said:
Everyone loves The Nose!
Yeah...I remember your tagging me with that moniker when I used this pic as my avatar on this forum:
...lee
-
2
-
1
-
-
13 hours ago, Vorticon said:
True, but it's still problematic if one wants to support current existing hardware.
There used to be an option to choose the size of the SAMS in Classic99, but it's now grayed out.
12 hours ago, Asmusr said:Could it be that different 1M cards work in different ways (some return the register value in both MSB and LSB and others only return it in the MSB)? I implemented the behavior that TheBF demonstrated in JS99er, but that broke the Stevie editor, so I changed it back.
To be compatible with current SAMS hardware, the returned LSB should always be ignored when reading the SAMS registers. SAMS hardware merely repeats the page number of the MSB in both bytes, whereas Classic99 does, in fact, return the bank# in the LSB and the page# in the MSB.
...lee
-
4
-
-
My TI-99/4A journey started in December, 1983, when my first wife bought one for our kids for Christmas after the price drop to $50. I was 40! When TI released TI Forth into the public domain that same month, I was hooked.
I first signed on to AtariAge with this post in May of 2011:
I’ve been enjoying interacting with this group ever since!
...lee
-
6
-
-
I know I mentioned this before, but I am thinking seriously of booting up fbForth 3.0 without enabling the fbForth ISR. It is enabled in fbForth 2.0. Besides enabling execution of user ISRs, the only reason to have it enabled is to use the fbForth speech and sound engines. This does not affect the BEEP and HONK words. Of course, you can always do sound lists per the E/A manual, with or without the fbForth ISR. And, you can always re-enable the ISR by jamming the contents of user variable INTLNK into >83C4.
The fbForth ISR does not take a lot of time, but it is not nothing. If you don’t need it, it slows the system a touch. Of course, you can always disable it by storing 0 at >83C4.
What do you think?
...lee
-
5 hours ago, TheBF said:
I like having the 64 column editor drop down into the bottom window. Thanks!
The next version of FBLOCKS will also allow exiting the old way, but with CTRL+9:
Future exits from 64-column editor:
-
FCTN+9: Exit editor to
SPLIT2SPLIT Text window - CTRL+9: Exit editor to mode from which editor invoked
...lee
-
2
-
FCTN+9: Exit editor to
-
-
1
-
-
5 hours ago, atrax27407 said:
Muchas gracias, Amigo! I have, however, found "a fly in the ointment". Blocks 70 and 71 BLK>file and FILE>BLK result in an error message and don't work properly.
My apologies! I actually have those working but forgot to compact and copy them to FBLOCKS. It will take me a little time to do that. In the meantime, here are the scripts: b2fexp.fbf f2bimp.fbf
...lee
-
1
-
-
14 hours ago, TheBF said:
Could you fire over your most recent FBLOCKS file as well?
11 hours ago, atrax27407 said:OK. Once again downloaded, HSGPL-modified, installed and awaiting the corrected FBLOCKS file. Will the individual applications reside on the same block #'s?
OK ... Here is a partially updated FBLOCKS: FBLOCKS
The utilities marked “...OK..” just before the block# on the menu have either been updated or shown to work with the current beta.
...lee
-
1
-
-
Wow! This took a bit of head scratching and code wizardry(?). Everything related to graphics mode switching seems to be working now. The 64-column editor also works fine. Here is the current beta: fbForth300_8_Na.bin
Gettin’ tighter!:
- bank 0: 162 bytes
- bank 1: 112 bytes
- bank 2: 118 bytes
- bank 3: 118 bytes
...lee
-
3
-
2 hours ago, apersson850 said:
A third version of this is that you use the high end of 2000-3FFFH, which seems unused by the p-system.
2 hours ago, JasonACT said:SAMS pages in 4K blocks, so can't you have your code at the high part of >3000 and switch pages at >2000 without causing issues like this?
Indeed, if the entire 4 KiB block at >3000..>3FFF is unused by the p-system, using >3000 (SAMS register address = >4004) as your only 4 KiB paging address, you are good for a single 4 KiB SAMS page window.
...lee
-
2
-
-
The problem with invoking the 64-column editor does, indeed, involve graphics mode switching. When the graphics mode is switched from non-bitmap modes (TEXT,TEXT80,GRAPHICS,MULTI) to bitmap modes (GRAPHICS2,SPLIT,SPLIT2) or vice versa, the system PABs (1user font file, 2 blocks files) are moved. The problem with the move is that the VRAM buffer address in each PAB does not get updated, so all hell breaks loose when the EDIT word is invoked with no intervening USEBFL (Use Blocks File). There may be one other VRAM location change that needs to be made, as well.
I may be able to split COLD into more than one routine such that a part could be invoked by the mode change code to make everything better without too much code bloat. We’ll see ....
...lee
-
2
-
-
12 hours ago, RickyDean said:
Enjoy your Florida trip, it's a bit rainy in this neck of the woods, but nice other wise.
We have enjoyed it since December 1. Returning to Maryland to, likely, rain April 2.
...lee
-
2
-
-
On 3/23/2024 at 11:39 AM, Lee Stewart said:
Yeah...any blocks with DSRLNK calls must be updated before they will run properly. I am nearly done with DSRLNK updates to the fbForth 3.0 cartridge. I will then get after FBLOCKS.
Thanks to you and @TheBF for your tests!
OK...I am pretty much done with the Chapter-8 File I/O changes for the new DSRLNK. I also have working DIR and CAT utilities for the new FBLOCKS.
I have been puzzling over what broke the 64-column editor and am reasonably sure it has to do with graphics mode switching and blocks I/O code. I did make changes to both and undoubtedly broke something. I did discover that, if I switch to Split mode before invoking the 64-column editor, it works. Exiting the editor shows issues, as well. I need to work through the mode-changing and blocks I/O code to shake out the bugs—too many balls in the air at once, I’m afraid!
Aside from bug fixing (may not get done until after return from Florida next week) and managing the DSRLNK changes for Alternate I/O (RS232 card) for KEY and EMIT (easy) , I am nearly done with the cartridge code for fbForth 3.0.
After I run down the bugs in recent code changes exposed by the 64-column editor, I will start knocking down the updates for FBLOCKS. Meanwhile, here is the current beta:
Current remaining cartridge space (some improvement! )
- bank 0: 162 bytes
- bank 1: 102 bytes
- bank 2: 184 bytes
- bank 3: 118 bytes
...lee
-
3
-
39 minutes ago, Vorticon said:
Is the data stored in the AMS pages preserved when when the mapper and card are turned off?
It should be there until you turn off the computer.
Also, there is really no reason to turn off the mapper unless you really want the start-up, transparent mode. I mentioned before that, once initialized in fbForth, the mapper is never turned off.
...lee
-
2
-
-
5 minutes ago, atrax27407 said:
There seems to be a problem with the latest FBLOCKS and the latest DSRLNK. I get errors when loading some of the BLOCKS (i.e., DIR) and some (but not all) others.
Yeah...any blocks with DSRLNK calls must be updated before they will run properly. I am nearly done with DSRLNK updates to the fbForth 3.0 cartridge. I will then get after FBLOCKS.
Thanks to you and @TheBF for your tests!
...lee
-
On 3/23/2024 at 10:44 AM, TheBF said:
Couple of things I just noticed but I may have an old version of FBLOCKS
The current version of FBLOCKS is 17LUL2023 and definitely not up to date. I have to update any blocks that use DSRLNK.
On 3/23/2024 at 10:44 AM, TheBF said:I do 6 LOAD. The compile flag EDT in block 12. I changed it to EDIT and it seems fine.
EDT is the main word in the 64-column editor. EDIT is redefined to run EDT in the EDITOR2 vocabulary.
On 3/23/2024 at 10:44 AM, TheBF said:Also the menu says "64 column editor"
Is the 64 column editor supposed to be the one in TEXT mode?
I always thought the 64 column editor was the one in SPLIT mode.
It does, indeed, run in SPLIT mode.
...lee
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
fbForth—TI Forth with File-based Block I/O [Post #1 UPDATED: 06/09/2023]
in TI-99/4A Development
Posted
It does save 4 bytes where the jump calculation is performed in ENDIF and BACK , and obviates the need for BACK , which saves 18 bytes for a total savings in the resident dictionary of 26 bytes.
It also saves 2 trips through the inner interpreter in compiling LOOP +LOOP UNTIL AGAIN because “ , ” replaces BACK (defined as “ HERE - , ”), but time savings while compiling are not usually that important.
...lee