Jump to content

TheBF

+AtariAge Subscriber
  • Content Count

    2,896
  • Joined

  • Last visited

Everything posted by TheBF

  1. Not sure if this gives you a little help, but it's an illustration in a manual I am working on. The Forth Programming Pyramid You program in Forth by adding functionality to the Forth system itself. Your WORDs are added to the system word by word and you can test each word as you go. This makes your pyramid of code very solid and reliable. · Assembler CODE words are the foundation of the language that control the computer hardware · The Forth language is normally written using a mix of those Assembler words and Forth · Your program’s words are just more words added to the system. No different than the Language itself. · All of this culminates in creating the final word that starts the entire program running which you can call anything you like. RUN is as good as any other. ​The word "RUN" in the pyramid could be anything, but it shows the last word (sub-routine) you create kicks off your entire program.
  2. Another way to go is to create a set of words that emulate the functionality of TI-BASIC to give you some higher level building blocks. Turbo Forth already has many of them already. For example: \ CALL clear in CAMEL99 Forth (Consult Turbo Forth docs for equivalent words) DECIMAL : CLEAR ( -- ) PAGE 0 23 AT-XY ; ( just because you love it ) \ make an input buffer CREATE BUF$ 80 ALLOT : INPUT$ ( -- BUF$) PAD DUP 80 ACCEPT BUF$ PLACE ; : INPUT# ( -- number) INPUT$ BUF$ ?NUMBER 0= ABORT" not a number" ; Warning CAMEL99 Forth "tries" to keep to Forth 94 standard. TF is Forth 83 Standard so there are some differences, but Willsy can give us the translations. ​
  3. Try writing an outline for the game like you would for an essay. The titles of the outline are the word names for the big blocks of the game. The names in the bullet points become the internal routine names. In other words design top down ... Then figure out how to build it Bottom up, testing your words as you build. Try the outline and post it here and we can give you support.
  4. That's a fun project. I am a musician and producer myself but have been programming for almost as long. Another exercise for you could be to open a file and have your note frequency calculator program print the values out to a file as BASIC DATA statements. Sort of like below. BUT please read the manual on the OPEN statement, I have not used TI BASIC for many years so my memory is faulty. 5 OPEN #1:"FILENAME" BLAH BLAH (check your manual) 10 LET F=110 20 FOR I=1 TO 91 30 PRINT #1: I * 100;" DATA "; F 40 LET F=F*92^(1/12)) 50 NEXT I 60 END But if you make the text file you could use it like a prefab building block for future music programs. Just an idea.
  5. Lol. It sounds Friday evening has started in Uk.😄
  6. This book has been the defacto text for many years and is a good adjunct to Willsys pages https://www.forth.com/starting-forth/0-starting-forth/
  7. I like the idea Mark. I am moving house but once we get settled I could help with editing and audio. I have a home studio. Well I did ... and will make a new one. Send me an email if you want to collaborate
  8. FYI by "easier to use" I mean it is interactive in a way that is hard to imagine for Assembly language programmers. You can write a simple code routine at the console like in BASIC and test it immediately. Do this a few times and join them all together as a high level Forth routine and test that interactively. It's pretty fun. B
  9. Well... Turbo Forth has its own Assembler. Which is easier to use than the TI assembler. So real Forth programmers write in Forth then optimize the right loops with Forth Asm routines. If you check the Tursi benchmarks postings you will see that I got the benchmark down to 6.5 seconds in Forth versus 5 seconds in the optimized Assembler version. And if I needed 5 seconds I would just write the outer loop in Forth Assembler too. Remember when Tursi re-wrote the code using BLWP system calls the way you would start a project it took 17 seconds versus 48 seconds in in-optimized turbo Forth. That is less than a 3 times difference in an apples to apples type comparison. There are industrial examples at Forth Inc where they rewrote customers products that were in Assembler or C where the final Forth version was faster because they could test algorithms interactively and find better methods to solve the problem. Algorithms normally beat language. BF
  10. I was just reading a paper on porting systems and it included these two quotes by famous computer scientists. Thought I would share here. I love the 1st one! And I have some experience to prove he's correct. "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." (Brian Kernighan) "The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague." (Edsger Dijkstra)
  11. How much faster is this than putting the one byte write line in a loop. Have you Measured it?
  12. Where do the robust libraries come from for your business? In house?
  13. Cool! Ya it's not too tricky to get started. The gotchas come on things like DEFER and TO where you have to remember to skip past the code fragment at the front of the word to get to the parameters. And if you plug in the addresses of code words anywhere you need remember to NOT skip over anything because there is nothing to skip. And it does make things a little bigger. On my system it added 220 or so bytes... not good news for a packed cartridge.
  14. Yes very different. A good cooperative tasker sounds like it would not be reliable but with fine grained control in the Forth environment you can tune the tasks very precisely. And when external inputs must be dealt with you only need to put the data acquisition routine(s) on an interrupt and queue the data somewhere. And problems with locks and semaphores disappear because you design routines to run to completion or exit at convenient places. There are some pretty big projects running this way on Forth systems. So here is a demo video that runs this code that just flails away at the screen with '-' and '.' while the console is still running. There is a bar graph task, showing the CPU loading, installed but I didn't run it in the video. 2taskdemo.mov
  15. Very sound advice for a preemptive task switcher. The Classic Forth task switcher is cooperative relying on much faster context switch times than is normal and switch only after I/O routines run to completion. All I/O routines are keep fast as well to allow smooth operation. Remarkably simple but also efficient. Forth Inc's Polyforth system could hang 150 dumb terminals on a i386 machine and users didn't complain. I know that sounds ridiculous, but they did it. So I will create a demo for you, but I know that there will not be an issue , because there are no surprises with these systems. They switch when you say and only when you say with a function called PAUSE but at very atomic intervals compared to what you are used to with other cooperative tasking systems. But to your point in your example, referencing via a register (R13) will not be a problem. But dead reckoning of an address in the code as a literal is.
  16. But SWPB+MOVB R0, <symbolic> is the same size as MOVB <symbolic>,<symbolic> and only uses 2 more cycles. Or am I missing something else?
  17. Actually the code I provided was Assembler, just a reverse Polish notation assembler. :-) <oldmanlecture> A very cool concept in Forth is the concept of compiling being nothing more than putting numbers into memory. (hopefully the correct numbers) There is an operator called "comma" and it looks like this , It is a number "compiler" in Forth. It takes a number from the stack and puts in in the next available memory location and incs the memory pointer by 2 bytes (for 16 bit machines) Typical usage would be just like a data statement HEX CREATE MYDATA DEAD , BEEF , ADDA , FFFF , MYDATA is equivalent to a label. Notice how you need to last comma to "compile" the last number into memory. With that little comma and some logic you can make an assembler in an afternoon. The weird thing is it's not a progam! Each mnemonic is it's own little assembler for 1 instruction. It's a totally different way to think about translating text to machine code. But since arguments go on the stack the registers come first then the instruction. </oldmanlecture> We now return to our regularly scheduled program.
  18. Ahh.... but you must pay for your sins for using register sorcery! I just realized that by referencing Registers as memory it makes all my code routines break as soon as I jump to a new task which has a new work space. Now I could use a slower muli-tasker that stays in 1 workspace, but how cool is it to have 20uS task switch on a TI-99?
  19. Yes that was what you had the benchmark do. These are clever tricks. I always knew it could be done, but thought it would be slower than using the instructions as designed. Wow. What a sad story for the 9900 designer. :-) So if I read the 9900 manual correctly: Using SWPB followed by MOVB R0,@>xxxx is 10+14+8 = 32 cycles, 6 bytes but using MOVB @>XXXX,@>yyyy adds is 14+8+8= 30 cycles, 6 bytes Correct?
  20. There is a pretty big article on the History of Forth here: https://www.forth.com/resources/forth-programming-language/ Chuck was probably aware of the things going on around him, but from what I gather he just hated Fortran. :-) And assembler was a slow development process. So he made Forth originally as just an interpreter to simplify batch jobs. LOL. From there he figured out the threaded compiler concepts. It seems the stack virtual machine has been re-invented independently by many people. Post-script, Java, Forth, Joy etc. Here is the quote that shows where Chuck lived: "To Moore, Forth was a personal response to his frustration with existing software tools, which he viewed as a sort of “tower of Babel” [Moore, 1970a]:"
  21. I bought TI Forth in 1984 (or so) The kernel was FIG-Forth 9900 published in the late 1970's. Was your board before that?
  22. Cool program. Thanks for the description. That portability is truly impressive. I spent a few years maintaining and upgrading a large factory testing program written in Turbo Pascal. I always felt comfortable with it. I don't remember how big it was but I know that after a year of working on it for the factory users I filled the memory and had to switch to huge memory model with pointers. It was pretty trivial to make the change. Wirth's ideas are very sound for sure. The funny thing is some of the stuff you are talking about with these complex compilers are problems created by the complex environment itself. By letting the machine control things you then have to provide ways for the machine to fix things too. It becomes a bit of a pyramid. That's one the things that shocks me about Forth is that by exposing everything to the programmer so much complexity melts away. Example for re-locatable code: Code goes where ever the variable DP (dictionary pointer) is set. Normally this is done by the compiler automagically as you add code to the system. But you are free to do whatever you want with it. The Forth dictionary of routine names is the lookup table so that is also covered. \ compile code in TI low memory >2E00 HEX 2E00 DP ! \ set the dictionary pointer : LOWMEM CR ." Hello low memory!" ; \ compile this in high memory >E000 HEX E000 DP ! : HiMEM CR ." Hello high memory!" ; ​\ code will continue to compile here until you move DP again When you expose the guts to the human and the system is so simple it's remarkable what you can do. However the learning curve is more akin to learning an operating system than a language so longer ramp up time for sure. But lots of fun nevertheless. Thanks again for giving us all the in depth insights on the P-code system. It's remarkable that they stuffed all that into the TI-99. Makes one imagine what could have been... :-)
×
×
  • Create New...