Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

2,637 Excellent

1 Follower

About senior_falcon

  • Rank
    River Patroller
  • Birthday 10/14/1951

Profile Information

  • Gender
  • Location
    Lansing, NY, USA

Recent Profile Visitors

11,077 profile views
  1. The compiled code is usually around 2/3 the size of the source XB program. In addition to that there is about 6K or more of runtime routines, depending on how complex your program is. So a 10 byte program will be around 6K long. A 9K program will be about 12K long and an 18K program will be about 18K long when compiled. This will vary depending on your programming style and how it happens to compile. If the compiled program turns out to be too big, there is the option of putting the runtime routines in low memory. But this only applies to straight XB. If you are using assembly support subroutines like The Missing Link, then this is not possible.
  2. Yep. The code to draw the line is exactly the same, but the XB code to determine where to draw the line and the color is compiled, so the end result looks like it is about 3x faster.
  3. Here is a little teaser for you. The two animated GIFs below show the LINES program from TMLDEMO. One of them is running in Extended BASIC and the other is compiled. Can you figure out which is which? (Remember that you won't get a 20x increase in speed by compiling TML. It already spends much of its time doing the graphics routines which are already in assembly. But any code in XB is MUCH faster.)
  4. I have worked out a few minor issues that arise when running T40XB with the compiler. Now the T40DEMO program works perfectly... Except that it is too fast now. When there are two CALL LINK("INPUT"...) statements in a row, it is hard to get off the enter key fast enough to avoid entering a null value for the second one. I will modify INPUT so that it will not start until no key is pressed. I will also add a DELAY to make it easier to port from XB to compiled XB. Using FOR/NEXT loops gives drastically different delays.
  5. I am super excited. I just ran a compiled version of T40DEMO which (almost) worked fine. It bypassed certain parts of the demo.I suspect that is because when I pressed "enter" it bypassed some of the steps before I got my finger off the key. (EDIT- I take it back. It did not bypass anything.) The beauty of this approach is that it should be able to work with any assembly subs you want to use
  6. in post #30, VOL wrote: However T40XB is still not polished enough. Its glyph for the tilde character is corrupted so I had to define it in this program. Thanks for catching that. In the T40XB included with the Betelgeuse3 package the tilde is one pixel higher than the one you defined and there is an extra dot in the bottom pixel row. The version of T40XB built into XB 2.8 G.E.M. has a tilde exactly like yours. I will see why this is happening and correct it.
  7. Very interesting. I like the trick with the FOR/NEXT loop. For me there is an interesting optical illusion. At first the waves scroll from bottom to top, but at some point they start scrolling from right to left!
  8. Now NUMREF, NUMASG, STRREF, and STRASG are able to pass values and strings back and forth between a compiled program and assembly language support routines. I was a little surprised when STRASG worked the first time! STRASG only requires 7 lines of code. This is a work in progress and there will be some nuances to work out. Of course, the gold standard is this: will it work with THE MISSING LINK? That has yet to be attempted. (Edit) CSN and CNS still need to be worked out.
  9. More progress: I can now NUMREF and NUMASG between a compiled program and assembly support routines. The assembly test program fetches a numeric variable from the compiled program with NUMREF, squares it, and and sends it back to the compiled program with NUMASG. Next up is STRREF which should be easy, then STRASG which will probably take more thought. (Edit) As expected, STRREF was straightforward. Now for STRASG.
  10. Classic99 is a windows program. I am quite sure it does not use the TI keyscan to detect F1 to break or restart the program.
  11. For what it's worth, I too have found that when break points are really close together, the second one is often skipped. There seems to be neither rhyme nor reason to it: If I tap F1 really fast it will sometimes break; if I hold down F1 it sometimes breaks; but many other times it just goes past the second break point without stopping. It could be my equipment: an old Dell rescued from the trash; the old keyboard which in Classic99 sometimes registers a double keypress; or Wndows XP running in a virtual box on a linux OS which is badly in need of updating. I have learned to live with it, adjusting the break points as needed so it will stop where I want it to.
  12. And don't overlook XB 2.8 G.E.M. which unlocks lots of graphics power, among other things.
  13. There have been a number of unsuccessful attempts at making an endless XB program possible. To my knowledge only XB 2.8 G.E.M. can seamlessly chain multiple XB programs together while retaining the numeric and string variables from one program to the next. From the XB 2.8 G.E.M. manual: CALL RUNL1(A$) RUNL1 is used to run an XB program from a running program. It is similar to CALL RUN but with a major difference. After it loads the program it runs the first line, but does not do a prescan or reset any of the variables of the calling program. By chaining programs together with RUNL1 you can create a very long XB program, and the neat thing is that bypassing the prescan means super fast start up time and that all the variables are automatically carried over into the newly loaded program. You don't have to save them before exiting one program and retrieve them in the next program. RUNL1 takes some liberties with the XB interpreter and to use it successfully, there are six rules that must be followed: If interested, you can read more about this technique on pages 12-13 of the manual.
  14. No, there are not any new illegal names. There will not be a version 8. This will add enough new functionality (assuming it actually works) that it will merit a new name. "Juwel"
  15. I have made some progress in adding assembly support to compiled code. So far a compiled program can CALL LINK to an assembly support routine and return to the compiled code. The two test A/L subs are simple; PRINTA fills the screen with "A" and PRINTB fills the middle of the screen with "B" As yet no variables can be passed in either direction with NUMREF, NUMASG, STRREF, STRASG. I have hopes these can be modified so this possible.
  • Create New...