TheBF

I have always found it inconvenient that I can save my Forth programs as E/A5 images but I have to include the compiler, interpreter and the dictionary headers with the program. I have been noodling on how to use the existing compiler to build a new Forth system on the TI-99 where we don't include words we don't need AND we don't include the dictionary headers either. Dictionary headers can take up to 30% of the total size of the binary image in a Forth program. This is not very different than the cross-compiler that I have that runs under MS DOS, but the one advantage I have on TI-99 is there is ton of code primitives in the kernel that are just there for the picking. I am calling this a "RECOMPILER" for now. I now have all the tools now on the TI-99 that I have in the DOS Forth so this could replace my DOS cross-compiler one day. All this thinking lead to the word IMPORT: which copies CODE words from the kernel into a memory buffer (low RAM) but keeps the dictionary info in a vocabulary in Camel99 Forth. It isn't a 100% solution because some of the kernel words jump into other words to save space, but most them are useable. For the regular Forth CODE words it's just this easy to "steal" their code for the new system. \ steal some primitives code from the Kernel and copy into target IMPORT: C! 2! 2@ COUNT +! C+! IMPORT: RP@ RP! DUP>R >R R> R@ SP@ SP! 2>R 2R> IMPORT: NIP ?DUP SWAP OVER ROT -ROT >< 2DROP 2DUP 2SWAP PICK IMPORT: AND OR XOR IMPORT: 1+ 1- 2+ 2- 2* 4* 8* 2/ IMPORT: 1+! 1-! IMPORT: - D+ RSHIFT LSHIFT INVERT ABS NEGATE ALIGNED IMPORT: UM* * UM/MOD M/MOD IMPORT: = OVER= 0< U< > < IMPORT: MIN MAX SPLIT FUSE IMPORT: MOVE FILL SKIP SCAN IMPORT: ON OFF Here is what it took to make IMPORT: (there are some words used below [ COMPILER T, ] that are defined in the cross-assembler and the preamble code) \ import.fth COMPILER HEX 045A CONSTANT 'NEXT' \ 9900 CODE for B *R10 Camel99 Forth's NEXT code : TNEXT, 'NEXT' T, ; \ Read code word from kernel, compile into target memory : TCODE, ( xt --) >BODY 80 CELLS ( -- addr len) BOUNDS ( -- IPend IPstart) BEGIN DUP @ 'NEXT' <> \ the instruction is not 'RET' WHILE DUP @ ( -- IP instruction) T, \ compile instruction CELL+ \ advance IP 2DUP < ABORT" End of code not found" REPEAT 2DROP ; : ?CODE ( xt --) DUP @ 2- - ABORT" Not a CODE word" ; \ like CREATE but takes the name from a stack string : CREATE, ( addr len -- ) HEADER, POSTPONE DOVAR ; \ IMPORT, finds a code word in the kernel and copies the code into TARGET \ It creates a VARIABLE in the Forth dictioinary that returns the target \ execution token in interpret mode. : IMPORT, ( addr len -- ) PAD PLACE \ save the name in PAD PAD FIND 0= ABORT" IMPORT, can't find" ( xt) DUP ?CODE \ CREATE/DOES> but with a string argument PAD COUNT CREATE, THERE , \ record the target address in Forth TCODE, \ compile code from Kernel into the target TNEXT, \ append NEXT to the TARGET code DOES> STATE @ ABORT" Can't run TARGET word" @ ( interpret mode, return the address ) ; : IMPORT: BEGIN PARSE-NAME DUP WHILE IMPORT, REPEAT 2DROP ; Next I need to make a version of VARIABLE CONSTANT : and ; and I should be able to recompile high-level Forth words and build a small program , in threaded code, that has no headers or branch/loop compilers built-in. I am envisioning this for making utility programs that don't require disk in the beginning, which means I should be able to put both stacks in scratchpad RAM.

"Removing resistance to education since 1823" 😁

BTW where did I go wrong? 16.66666 ms per tick ~= 60 ticks per second. Edited per Lee's correction 2^32= 4,294,967,296 ticks / 60 = 71582788 seconds / 60 = 1193046 minutes / 60 = 19884 hrs / 24 = 828.5 days = ~ 2.27 years

LOL. Thanks! That's even better. Essentially don't worry about it.

Over on comp.lang.forth I fellow posted a link to this site. It is aruably the cleanest source code to describe a Forth kernel I have ever seen. Primitives are in intel Assembler and then another file shows the high level words as Forth source. T3XFORTH - T3X.ORG (I may just try to cross-compile it on TI99 if I get some time)

Ach! Yer a wild one lad.

While snooping around the internet I found a version of XMODEM written in Forth83 dated Sept 1985 but ported to ANS Forth in 2010. I am looking at how hard it will be to make it run on Camel99 Forth. I think it's doable. That would be really handy for sending/receiving files to real iron with CAMELTTY Forth running on my TI99. One thing that it needs is a long duration timer. I remembered playing with an ISR based 32 bit counter. I went back to that code and reflected on something that MPE Forth had back in the 1990s. That is, a programmable timer "creator". The concept is that you make a word that records a duration and a time in future. (DURATION+CURRENT_TIME) Every time you use that word it checks if the current time is past the future time you set. If is not, just return false. ELSE if it is past the current time, the timer has expired so... Reset the future time one more duration in the future, and return true. With 16mS interrupt ticks and a 32 bit unsigned number you can keep continuous time for over 19 hours. 828 days. Edit: Oops bad math. Edited. Edited again. \ This allows timing up to: \ 1/60 * 2^32 \ = 71,582,788 seconds \ = 1,193,046.5 minutes \ = 19,884 hours \ = 828.5 days However you have to use double integer computations and comparisons. Here is what I came up with. I have not figured how to deal with what happens if the master timer rolls over to zero except to say reset the master timer when the program starts? There is also problem here with the current ELAPSE function in that it RESETS the master timer but since that is mostly for interactive testing at the console, I will ignore it for now. (wouldn't take much to fix it) But for XMODEM waiting for packets to start and such this would be great because you just poll the timer you made as you have time. The ISR is keeping track of real time.

Why am I not surprised. 🙂 Thanks Bill. It's good for me to see Assembler from a veteran. I have this weird Assembler that's like Forth: 2 stacks built in colon/semi-colon for nestable sub-routines constants variables allot Nestable down-counting FOR/NEXT loop The difference is you have to explicitly name the registers and variables in your code even stuff that's on the stack. But it assembles native code. It's kind of fun to play with. I translated your sieve benchmark to it and it runs in the same time frame. If you are curious it's here: ASMFORTH/demo/ASMFORTH-SIEVE.8.FTH at main · bfox9900/ASMFORTH (github.com) I will take a spin a translating your lines code to that language for my amusement.

I think that chip has a bug.

That is a thing of beauty, and a thing of beauty is a joy forever as a workmate of mine used to say. I would love to see how that code does what it does if that's possible.

A team approach like that would probably get results. I spent 15 years at a TV station. TV took some of its job titles/descriptions from the film industry. It was very clear who did what and I remember wondering how it was done in the computer game world. TV Team (from memory) Producer final say on everything Technical Director Camera operator(s) Lighting Audio Chryon operator (digital graphics machine) Art department (create still content and graphic elements) Production Assistant (keep track of stuff. Producer's right arm) Script Assistant Talent (in front of camera) I know in the sixties Fred Brooks in "The Mythical Man Month" prescribed creating teams like a surgical team. I am guessing he had never had experience in film to know that hierarchy. For interest here are his job titles: Surgeon the boss Co-pilot Administrator Editor Two secretaries Program clerk (docs) Toolsmith Language Lawyer I think some of the TV/Film groups would make more sense these days in video games. My 2 cents (Canadian, only ~1.6 USD)

Thanks very much for the bug report and TIPI instructions. I noticed that 'ls' error too after I posted. I think I will have to assign a default filename like "untitled" to handle the :wq issue the simplest way. If there was no filename given at the vi command, the filename string is empty so that causes the error. I don't know what vi does so I will check that and emulate as best I can. I will add these to the issues list in the repository. I will get back to this again. I went down a compiler rabbit hole this week. If it is not a lot of trouble could you post your edited vimanpage file? oops! I missed that you did post it. Thanks! I will just make it part of the package. That would make it a true FOSS project .

That's above my pay grade but it seems to have pointers so if you can return a pointer to function ... Modula-2 tutorial: Pointers and Dynamic Allocation (modula2.org)

Wirth was one those guys that did great work, but didn't get enough respect IMHO. After Pascal he went on to Modula and proved it could build an operating system. I think he even had custom silicon for one of his projects. How many millions of man hours were wasted waiting for C to compile compared to if people had been using a fast compiling language like Modula. Things I wonder ...

Who is bringing the schnaps (Akvavit) ?

Just found this on Hacker News. The original VI source code for UNIX System V. I don't know if can glean anything from this but it's worth a look. https://github.com/Cube9999/vi/tree/master

Truly, you are a wise man.

A conflict in the CRU addresses or incorrect address settings on the devices is a very probable cause. My understanding: The TI DSR system searches these cards in order of their CRU address to find the function requested by a program. (1000,1100,1200...) There can be cases where we want specific cards to be searched in a specific order or things won't work correctly. In most cases TIPI needs to be first in line.

Ok. Here is the latest version, 0.9 that boots with AUTOBAUD waiting for an "enter" key. I fixed a bug in backspace key ( I think) and I removed the debug display on the VDP screen because that really slowed down the command loop. If you put the VIMANPAGE on the disk with the program files, the help command will pull it up in "view" mode (read only) All bug reports/feature requests welcome. VI99TTY VI99TTZ VI99TT[ VIMANPAGE

Absolutely brilliant man. Keep yourself well.

Apparently your abilities are much higher than you admit to. This is amazing. What a super contribution to the group.

That's funny for me because I used to work for a Chief Engineer here in Canada who was German and now I many times now go looking for "ein Schraubenzieher" because I heard it all the time.

If TI had understood where the future of desktop machines was going your architecture with a 99000 processor could have challenged the IBM PC. (Assuming a nice O/S, good developer support and a very large marketing budget) But it does sound like the kind of thing we were all waiting for. The "TI-99/10".

I forgot that I have a new Graphics2 mode library so I had to give that a go. It's not really fast but it plots. \ Circle in bitmap mode for Camel99 Forth NEEDS DUMP FROM DSK1.TOOLS NEEDS VALUE FROM DSK1.VALUES NEEDS MARKER FROM DSK1.MARKER NEEDS PLOT FROM DSK1.GRAPHICS2 NEEDS SIN FROM DSK1.TRIG DECIMAL 96 VALUE Xbias 127 VALUE Ybias 130 VALUE Scale 0 VALUE XCNTR 0 VALUE YCNTR : ENUM ( 0 <text> -- n) DUP CONSTANT 1+ ; 0 ( set 1st color) ENUM TRANS ENUM BLACK ENUM GREEN ENUM LIME ENUM BLUE ENUM SKY ENUM RED ENUM CYAN ENUM RUST ENUM ORANGE ENUM YELLOW ENUM LEMON ENUM OLIVE ENUM MAGENTA ENUM GRAY ENUM WHITE DROP : PAINT ( color ) 4 LSHIFT INK ! ; : SIN() ( n -- x) SIN Scale / Ybias + ; : COS() ( n -- y) COS Scale / Xbias + ; : DIAMETER ( n -- n') 20000 SWAP / TO Scale ; : CENTER ( 0 0 -- ) 2/ TO YCNTR 2/ TO XCNTR ; : CIRCLE ( x y diameter -- ) DIAMETER CENTER 360 0 DO I SIN() XCNTR + I COS() YCNTR + PLOT LOOP ; DECIMAL : RUN GRAPHICS2 RED PAINT -70 0 10 CIRCLE MAGENTA PAINT -60 0 40 CIRCLE LIME PAINT -50 0 80 CIRCLE YELLOW PAINT 30 0 190 CIRCLE BEGIN KEY? UNTIL TEXT ; CIRCLES.mp4

That kind blows my mind. Well done.