TheBF

Also if you still "need" to watch commercial TV it's being broadcast in High-definition and can be watched for free with your "offline" TV with a $50.00 Antenna. I have encountered a lot of people who don't know that broadcasting TV still exists. (not sure for how much longer however)

I am guessing that he is also a button accordion player so the the C64 is an easy transition. They are more popular in Europe than in N. America.

I found a Forth system on my disk that I had kept since I don't know when. It is from 1991, called ZenForth, by Martin Tracy. I has this definitions to read keys into memory without echo. : (keys) ( a +n) >R 0 ( a o) \ read upto +n chars into address without echo; stop at #EOL BEGIN DUP R@ < WHILE KEY DUP #EOL = IF R> 2DROP DUP >R ( early out) ELSE BL MAX >R 2DUP + R> SWAP C! 1+ THEN REPEAT SPAN ! R> 2DROP ; I found this to be hard to understand and wondered could it be simpler. Here is what I came up with. \ Like ACCEPT but no echo nor backspace : KEYS ( a +n -- n ) TUCK ( -- n a n) BEGIN DUP WHILE KEY DUP 13 <> WHILE \ BL MAX \ optional character filtration 2 PICK C! \ store key 1 /STRING \ move to next address, dec count REPEAT DROP \ drop the 'cr' THEN NIP - ; 19 words versus 28 Forth words (I removed the BL MAX from mine so we could remove it from Martin's version) Now to be fair Martin could not do multiple WHILE statements in ZenForth and I am not sure the the clever word /STRING was on the scene yet. Amazing what can happen in 33 years with a "dead" language.

With number three you could make it work like the old "line" editing commands by adding a CR I think. : CLS 0 60 (LINE) DROP 1024 BLANKS ; : P ( n-- ) 60 (LINE) CR EXPECT ; Then edit away CLS 0 P ( THIS WILL GO TO THE TOP LINE ) 2 P : HELLO CR ." HELLO WORLD" ; ( tiniest editor ever)

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

And in fact the hardware on the 1M card does the same as we can see in the image. Here I turn on the card and then dump the registers at >4000.

(That's my weird way to say I think you are doing amazing stuff with the P code card.)

You are allowed one bug a week I believe. I am always over my limit.

Ooo thanks for thls link. Are you a fiddler?

Since its simple to install it I don't see a downside to leaving it out at boot time.

I like having the 64 column editor drop down into the bottom window. Thanks! I am having flashbacks to 1984. I believe that editor was first developed by Dr. C. H. Ting, who passed away just last year. It's a damned clever hack.

Could you fire over your most recent FBLOCKS file as well?

Now that we know that >3000..>3FFF is free that seems like the best solution to me. There are very few problems with just having one window for SAMS. The only time you need to think about it is if you want to copy from SAMS page to SAMS page. That will require reading some SAMS data into normal memory, change page and copy it back. I ran into this with the ED99 editor and ended up using two "windows" so I could copy records SAMS-to-SAMS with the most efficiency but it is a luxury in a tiny machine like 99. Not a necessity.

DSR_spec_for_ti994a_PC_V2_0_03_28_1983.pdf

I have something working that has me quite excited. I knew it was possible but I couldn't quite get my brain around it for all this time. The idea is to leverage the ANS Forth "wordlist" system, used to implement vocabularies, to make "overlays" ( and in future SAMS modules) Overlays will let you have pre-compiled blocks for code for a specific purpose on disk, that you can bring into the system quickly. This is similar to the BSAVE/BLOAD function in FbForth. In ANS/ISO Forth each vocabulary is a "stand-alone" dictionary that ends with a null string. ( a zero) The way you add them to the search is by putting them in short list of other vocabularies. Forth then searches those lists one at a time, in the order you placed them. The commands to control the search order are: ONLY which clears the search order to a short list of words and FORTH ALSO which ads vocabularies to the search-order list. For example, the following commands put the vocabularies called FORTH, EDITOR, ASSEMBLER and MYSTUFF into the search list, in the reverse order that you read them. (of course. It's Forth. It's kind of like a stack of wordlists, last one is on top) ONLY FORTH ALSO EDITOR ALSO ASSEMBLER ALSO MYSTUFF If we added the word DEFINITIONS then all new definitions that we make would compile into MYSTUFF. What I wanted was a way to make a vocabulary that worked just like the normal ANS version but the wordlist and Forth code lived in Low RAM. When invoked this overlay vocabulary has to put itself in the search order but then also save the Forth dictionary pointer and switch it to the dictionary in LOW RAM. Doing that meant I had to revisit wordlists and really understand how all this stuff works and I finally got it. The overlay "vocabulary" is called OVERLAY. Here is the very "green" code The video shows it in action.

Does anyone know if the source code survived over all these years?

Google can't seem to find anything using: TI-99 LISP I wonder where it's hiding?

Indeed. My MOVE program tests for overlapping memory and chooses one of two different loops. I might have an problem with that overlap detector.

Interesting idea RICH. I have code for a LISP (well scheme actually) interpreter written in Forth that I have wondered about trying to port. SAMS would definitely give it some room to be useful.

Wow! Your are so right @matthew180. I had no idea. I replaced the MOVE program with MOVEW which uses MOV in a loop to move memory words. There is almost no difference in speed now. For reference here is MOVEW in Forth Assembler.

For full disclosure VIRT>REAL "program" is written in Forth Assembler also. (It uses machine code in the system to avoid loading the assembler.) HEX CODE VIRT>REAL ( virtaddr -- real_address ) \ Lee Stewart's code to replace >1000 UM/MOD. 2.3% faster C020 , SEG , \ SEG @@ R0 MOV, \ segment# to R0 0A40 , \ R0 4 SLA, \ page# segment starts C144 , \ R4 R5 MOV, \ address to R5 0245 , 0FFF , \ R5 0FFF ANDI, \ page offset 09C4 , \ R4 0C SRL, \ page of current segment A100 , \ R0 R4 ADD, \ bank# 8804 , BANK# , \ R4 BANK# @@ CMP, \ switch page ? 1309 , \ NE IF, C804 , BANK# , \ R4 BANK# @@ MOV, \ YES, update BANK# 06C4 , \ R4 SWPB, 020C , 1E00 , \ R12 1E00 LI, \ select SAMS 1D00 , \ 0 SBO, \ card on C804 , SREG , \ R4 SREG @@ MOV, \ map the page 1E00 , \ 0 SBZ, \ card off \ ENDIF, 0204 , PMEM , \ R4 PMEM LI, \ page_mem->tos A105 , \ R5 R4 ADD, \ add computed offset to page NEXT, \ 46 bytes ENDCODE

I take your point that MOV would be a better test than MOVB as I am using in my program. I can check that too.

Yes it's Forth but MOVE is written in Forth Assembler. Forth is just the console to call the program and put it in a loop. CODE MOVE ( src dst n -- ) \ forward character move *SP+ R0 MOV, \ pop DEST into R0 *SP+ R1 MOV, \ pop source into R1 TOS TOS MOV, NE IF, \ if n=0 we are done \ need some copies R0 R2 MOV, \ dup dest R0 R3 MOV, \ dup dest TOS R3 ADD, \ R3=dest+n \ test window: src dst dst+n WITHIN R0 R3 SUB, R1 R2 SUB, R3 R2 CMP, HI IF, \ do cmove> ............ TOS W MOV, \ dup n W DEC, \ compute n-1 W R1 ADD, \ point to end of source W R0 ADD, \ point to end of destination BEGIN, *R1 *R0 MOVB, R1 DEC, \ dec source R0 DEC, \ dec dest TOS DEC, \ dec the counter in TOS (R4) EQ UNTIL, ELSE, \ do cmove ............. BEGIN, *R1+ *R0+ MOVB, \ byte move, with auto increment by 1. TOS DEC, \ we can test it before the loop starts EQ UNTIL, ENDIF, ENDIF, TOS POP, NEXT, ENDCODE

That Tursi is not just a pretty face. I wrote up a better test (I think) that uses MOVE which is an Assembly language word that moves bytes. On real hardware, it takes 4K of data from ROM at >0000 and writes to 64K of SAMS in 4K chunks (16 pages) I then did the reverse and wrote the SAMS data back to ROM. Reading is much faster. Edit: Changed WRITEPAGES to do exactly the same thing as READPAGES

So my quick and dirty result is the opposite. (of course they did) I think it's because when I read SAMS I have to throw away the result with DROP so that's extra time spent in the loop. The test code reads a 64K chunk of SAMS memory as 32K memory words. The SAMS code is assembler and the tests are Forth. There is computation to convert a virtual address (0..>FFFF) to the real address in RAM so that takes a bit of time. The screen shot shows the results.