Improving TI BASIC performance

[RXB]

1 hour ago, apersson850 said:

Seems good, but it's a different issue. That's for accessing values frequently used. At least it should be, or there's no point. But if you only want to do an occasional check if a byte is larger than 32, for example, then a CB @BYTETOCHECK,@DD32, where DD32 contains the value 32, is the most efficient. This is true also if the byte to check is in a register. Then you do CB R2,@DD32.

If you repeatedly want to compare against 32, then you should do a MOVB @DD32,R1 first, and then compare CB R2,R1.

In any case, the value 32 has to come from somewhere.

A common trick it to find that in the source code listing and use that value so

LABEL CI  R7,>3200

L32     EQU $-2

is in code but you can reference with L32 for the byte >32 later.

This way it does not need to be stored somewhere again.

[RXB]

1 hour ago, apersson850 said:

Take a VERY good look at your own posts in the past, and try to count who's the most arrogant!

Why did you say this? What purpose does it accomplish?

[senior_falcon]

Here is MMXB2.OBJ

This has the faster CALL CHAR. I just compared this with standard BASIC and XB, running at the same time. Looping 1000 times:

XB 134 seconds, Basic 181 seconds, MMXB 54 seconds (the programs were run simultaneously so the results should be comparable to each other even though the times may be off)

 

CALL CHAR is modified to define characters from 0 to 159   

Character patterns from 0 to 3 are in the color table, so you can define 8 color sets at once if you are clever. Do not use characters from 24 to 29

CALL COLOR is modified to define colors in all the character sets from 1 to 32

     character set       ascii             vdp ram

      17                    160-167         >0300

      18-28 omitted; If you set a character set in this range (17-28) to the same FG and BG, you set the color of the "unused" characters, which can be used for borders, etc.

      29                     0-7                >030C

      30                     8-15              >030D

      31                    16-23             >030E

      32                    24-31             >030F

 

CALL CHAR can write to the vdp rollout area, which will probably crash the program. To avoid this do not use characters from 24 to 29.

Both CALL CHAR and CALL COLOR can write to the sprite table in vdp ram from >0300 to >037F.

With some cleverness you can use these to define sprites, but care must be taken to get the desired results.

 

To load in Classic99

Enable GRAM at >2000 and >4000

From Basic:

CALL INIT

CALL LOAD("DSK2.MMXB2.OBJ")

CALL LINK("WTGROM")

MMXB2.obj

Edited June 15, 2022 by senior_falcon

[apersson850]

12 hours ago, RXB said:

A common trick it to find that in the source code listing and use that value so

LABEL CI  R7,>3200

L32     EQU $-2

is in code but you can reference with L32 for the byte >32 later.

This way it does not need to be stored somewhere again.

That's a trick some use, yes. It's considered an ugly trick, one you should avoid as long as possible, since it means that if you change the code for some reason, you constant may change.

[apersson850]

12 hours ago, RXB said:

Why did you say this? What purpose does it accomplish?

Probably doesn't accomplish anything, since teaching you manners seems very hard, if not impossible.

[oddemann]

5 hours ago, senior_falcon said:

Here is MMXB2.OBJ

This has the faster CALL CHAR. I just compared this with standard BASIC and XB, running at the same time. Looping 1000 times:

XB 134 seconds, Basic 181 seconds, MMXB 54 seconds (the programs were run simultaneously so the results should be comparable to each other even though the times may be off)

This is very interesting!

[oddemann]

Can this be integrated into Classic99 as it's on Basic ver.?

That is a huge jump in speed and I would love to have a "Press 2" for MMX Basic 2! in Classic99.

[speccery]

2 hours ago, oddemann said:

Can this be integrated into Classic99 as it's on Basic ver.?

That is a huge jump in speed and I would love to have a "Press 2" for MMX Basic 2! in Classic99.

My five cents: it could, but in my opinion the beauty of this approach is that it doesn’t have to: just enable GRAM and choose mini memory cartridge, and load the object and you’re done  

[senior_falcon]

3 hours ago, apersson850 said:

That's a trick some use, yes. It's considered an ugly trick, one you should avoid as long as possible, since it means that if you change the code for some reason, you constant may change.

Yep, I've been bitten by that a few times.

[senior_falcon]

5 hours ago, oddemann said:

Can this be integrated into Classic99 as it's on Basic ver.?

That is a huge jump in speed and I would love to have a "Press 2" for MMX Basic 2! in Classic99.

Console Basic is in groms 1 and 2. With grom 3 in the cartridge as the MiniMemory grom, those 2 groms could be copied over to groms 4 and 5 in the cartridge. The changes could included in that second version of Basic and there would be 2 Basics in the menu: Press 1 for TI BASIC and Press 4 for MM BASIC. There is room in the MiniMemory rom for the assembly instructions so it would be a tidy package. There might even be enough room for some 40 column support.

But I personally do not have any interest in moving Basic and the debugging that would inevitably go with that. If someone else were to do that then the rest is simple.

Edited June 15, 2022 by senior_falcon

[RXB]

7 hours ago, apersson850 said:

That's a trick some use, yes. It's considered an ugly trick, one you should avoid as long as possible, since it means that if you change the code for some reason, you constant may change.

Why I use it in ROM for XB.

We have been using this same code in ROM for over 30 years it does not change often.

[RXB]

7 hours ago, apersson850 said:

Probably doesn't accomplish anything, since teaching you manners seems very hard, if not impossible.

And again, uncalled for, as I am not the one being offensive here.

Do you call these good manners?

[RXB]

7 hours ago, oddemann said:

This is very interesting!

With a loop that is how you measure better, been saying this for some time now.

With some math you can get it down to millionths of a second.

[RXB]

4 hours ago, senior_falcon said:

Yep, I've been bitten by that a few times.

Can you show the source code for it?

[oddemann]

3 hours ago, RXB said:

With a loop that is how you measure better, been saying this for some time now.

With some math you can get it down to millionths of a second.

Please do not "loop" me into that garb! And I did not reply to you!

[Tursi]

9 hours ago, speccery said:

My five cents: it could, but in my opinion the beauty of this approach is that it doesn’t have to: just enable GRAM and choose mini memory cartridge, and load the object and you’re done  

You could also create an INI entry for it to show up in the cartridge menu. The selected cart is loaded after the system memories, and is allowed to overwrite them.

 

[apersson850]

4 hours ago, RXB said:

And again, uncalled for, as I am not the one being offensive here.

Do you call these good manners?

You are constantly offensive here, with "here" being in this forum. For some reason.

I've ignored it for years, but not any longer.

[apersson850]

4 hours ago, RXB said:

Why I use it in ROM for XB.

We have been using this same code in ROM for over 30 years it does not change often.

Yes, that's an unusually stable code. There it can work.

[apersson850]

I did once publish an article about the reason for Pascal being as slow as it is. Or as fast as it is, depending on which features you value most.

Now, in this discussion about making a new BASIC interpreter, I realized that some of the concepts I touched when describing parts of the PME (P-Machine Emulator), the program which interprets p-code, could be worth a more detailed description.

For what it's worth, I publish the modified article here. The description of the PME is more detailed in this one.

Is Pascal slow.pdf

[speccery]

Spent just now a few hours improving the StrangeCart. I added a new command CALL GRAM(X). The parameter X can be used to switch on GRAM functionality for system GROMs (24K allocated for that), copy the system GROMs to that area, and finally turn on GRAM writes to selected GROM areas. 

For example CALL GRAM(256+6) turns on system GROM override and copies GROMs 0,1,2 into the overridden area. This is the effect of the value 256. The low 8 bits turn on writability to GROM "chips", bit 0 (LSB) makes GROM 0 writable, bit 1 makes GROM 1 writable, and so on. Thus is total CALL GRAM(256+6) turns on override, copies in system GROMs from console to the strangecart, and finally enables writing to GRAM 1 and 2 (i.e. addresses from >2000 to >5FFF). Without writes to the system GROM area things continue to operate normally.

 

Once those things are done, the normal MiniMemory operations CALL INIT, CALL LOAD, and CALL LINK from the top of this thread can be done - and the code developed by @senior_falcon works on the real iron! I.e. the speedup for CALL VCHAR is realized, proving that the system GROM override worked, as the runtime fell from 40 seconds to 25 seconds.

 

Thus with these updates the StrangeCart is simultaneously a MiniMemory module, GRAM and system GROM override device.  My special build of MiniMemory ROMs and GROMs is not entirely compatible with a normal MiniMemory, since my version has extra Basic commands and acts as the gateway to StrangeCart Basic. Which incidentally runs the the VCHAR loop in 0.25 seconds...

[+OLD CS1]

1 hour ago, speccery said:

Thus with these updates the StrangeCart is simultaneously a MiniMemory module, GRAM and system GROM override device.  My special build of MiniMemory ROMs and GROMs is not entirely compatible with a normal MiniMemory, since my version has extra Basic commands and acts as the gateway to StrangeCart Basic. Which incidentally runs the the VCHAR loop in 0.25 seconds...

[HOME AUTOMATION]

3 hours ago, speccery said:

Which incidentally runs the the VCHAR loop in 0.25 seconds...

Only 100 x faster... I need exaflops!

 

[speccery]

12 hours ago, HOME AUTOMATION said:

Only 100 x faster... I need exaflops!

 

Yes it's only 100x faster, since my Basic is not yet optimised but more importantly it still needs to ask the TMS9900 to go and write stuff to VDP memory. A cartridge unfortunately can't become a bus master on the TI-99/4A, in fact there is no DMA capability anywhere in the TI-99/4A architecture. In this type of VCHAR loop probably at least 90% of the time goes to waiting the TMS9900 to do its thing. I actually measure it, but the measurement is currently tied to a 100 microsecond timer interval which is too granular. I can easily setup timers to for example 100 nanosecond interval which would enable much more accurate measurements of the time it takes the TMS9900 to do something.

[HOME AUTOMATION]

21 hours ago, speccery said:

I.e. the speedup for CALL VCHAR is realized, proving that the system GROM override worked, as the runtime fell from 40 seconds to 25 seconds.

Oops, I should have compared your improvements to the original time of 40 sec..

 

That's 160x faster! Still, less than I presume is required for me to overthrow all the other hackers out-there.

[speccery]

I just wrote an update about my TI-GROMmy project. It supports the GROM writability as required by the MMXB.OBJ described in the first message of this thread.

 

By the way, if anyone has other similar pieces of code (modifying system GROMs) I would be very interested in testing that with TI-GROMmy.