It does the same demo as yours but starts at bottom and twice as fast as XB, also faster then your demo.
(But I assume your demo in Assembly has delays in it to slow it.)
A couple of points:
If my compiled demo just has "Hello World" then it is twice as fast as your version in RXB. But you have a good point - as the string gets longer then it takes longer to print to the screen. You have to remember that these programs get there via very different paths. The compiled version does it the TI BASIC way: it takes a string, uses SEG$ to extract a one character string, converts to an ASCII number, uses HCHAR to get a row and colum and prints the ascii at the screen location. That's a lot of steps and they have to be done for each character. In your RXB program the bottleneck is at the beginning: it takes time to CALL the routine, to fetch the string and the screen location, etc. Once that is done then it can efficiently move the bytes to VDP memory. Writing 200 bytes wouldn't take very much longer than writing just one byte - the initial overhead is the same.
One thing you can be sure of is that I would not intentionally put delays in the compiler as the whole idea is to run as fast as possible. I chose the TI BASIC method not as an example of how you should print text on the screen (It's a lousy way to do that) but just as an example of how much the compiler can speed up the code and how easy it is to modify the original XB program with the new package.
In XB256 there is a subroutine called DISPLY that is used to print text on the screen. I mimicked your program but used DISPLY instead and the results are in the video below. The programs are running in RXB and XB and you can see that they run at virtually the same speed.
I don't want people getting the idea that my poor old compiler is hard pressed to keep up with XB or RXB, so I then break my program and run the same program that has been compiled. I think you will be able to detect a difference...
(The choppiness is because the frame rate is too slow)
(edit) In fairness to RXB, Rich's example could be sped up a lot by including a space after Hello World and eliminating the 2nd 1 byte long string. This cuts the overhead in half and and it runs twice as fast as the similar assembly subroutine DISPLY.
How can that be? It turns out that XB and RXB are considerably faster performing a CALL compared to performing a CALL LINK. Additionally, it takes longer to pass strings and numbers to the routine when using CALL LINK. So CALL LINK starts out slower. Once it is running the assembly routine should always be faster, but in this case that is not enough to make up for the slow start.
Edited by senior_falcon, Thu Feb 15, 2018 11:20 AM.