TI Basic move crunch buffer in assembly

[+retroclouds]

** This question is about the crunch buffer in TI Basic, not the crunch buffer in Extended Basic **

 

ok, so I have been doing some experiments with TI Basic lately.

 

For one of the tests I'm doing I am using the F18a with 30 rows mode. What I would like to do is add some information on the rows 25-30.

The thing is that the VDP memory for that area is "blocked" by the TI Basic crunch buffer that starts at VDP >320

 

So here are my questions:

 

Is it possible to move the TI Basic crunch buffer to another location in VDP memory? I presume it's hardcoded in the TI Basic interpreter in GPL.

Was thinking about using a ISR routine in assembly routine that "kicks-in" and changes addresses (GPL registers, addresses) in a transparent way.

Considering that TI Basic is so slow I might actually get away with it

 

Any ideas on this one? 

 

Is the TI Basic disassembly available somewhere? I'm aware of TI XB disassembly, but not TI Basic itself.

Actually I start liking TI Basic much. Yes it's slow, but I'd like to learn a lot more about its internals before addressing TI Extended Basic.

 

 

 

 

[+mizapf]

1 hour ago, retroclouds said:

Is the TI Basic disassembly available somewhere? I'm aware of TI XB disassembly, but not TI Basic itself.

Have a look at Heiner Martin's TI INTERN. We should even have the PDF somewhere.

[+RXB]

It would not be that hard to move all the VDP around in TI Basic including the Crunch Buffer and other VDP settings.

In RXB I have routines to move VDP Stack and Memory locations so this shows it can be done.

The issue would be crashing Assembly Support as a result so no EA support would work without rewrite of EA cart and support routines.

Thus it can work but any Assembly would crash due to locations moved. Again I can be done, just troublesome.

Edited September 23, 2021 by RXB
Spelling

[senior_falcon]

58 minutes ago, RXB said:

The issue would be crashing Assembly Support as a result so no EA support would work without rewrite of EA cart and support routines.

Thus it can work but any Assembly would crash due to locations moved. Again I can be done, just troublesome.

I don't understand why you think assembly support would not work.

 

@Retroclouds: Your reference to using an ISR hook makes me think that by TI BASIC, you mean TI BASIC as implemented by the E/A or MiniMemory cartridge. Are you talking about 32 rows of 32 characters, or 32x80? For what it's worth, BASIC can use a 24x40 screen without interfering with anything important. It is almost as if they designed it that way. I can find the memory map tonight if you are interested in pursuing that.

The manual for MG Explorer has some nice memory maps in the back.

Edited September 23, 2021 by senior_falcon

[+RXB]

1 hour ago, senior_falcon said:

I don't understand why you think assembly support would not work.

 

@Retroclouds: Your reference to using an ISR hook makes me think that by TI BASIC, you mean TI BASIC as implemented by the E/A or MiniMemory cartridge. Are you talking about 32 rows of 32 characters, or 32x80? For what it's worth, BASIC can use a 24x40 screen without interfering with anything important. It is almost as if they designed it that way. I can find the memory map tonight if you are interested in pursuing that.

The manual for MG Explorer has some nice memory maps in the back.

You will find HARD CODED ADDRESS in ROM 0, GROM 0, GROM 1 and GROM 2.

And ISR Hook is used to override this problem in many utilities that change these address.

I prefer to just fix the issue instead of circumventing it.

I do think a updated ROM 0, GROM 0, GROM 1 and GROM 2 is due.

[+Vorticon]

1 hour ago, senior_falcon said:

For what it's worth, BASIC can use a 24x40 screen without interfering with anything important. It is almost as if they designed it that way.

In other words one could adjust the proper VDP registers to punt Basic into Text mode? 

[senior_falcon]

25 minutes ago, Vorticon said:

In other words one could adjust the proper VDP registers to punt Basic into Text mode? 

Yes, that is no problem

[+RXB]

But then you are not really in BASIC anymore are you?

As you might just have to write an entire program devoted to that change.

Impossible to say it is backwards compatible as it is not even same environment anymore but an entire new one dependent on what is loaded.

You could run a Forth or Pascal or LISP program that way, but calling it BASIC still would be just the start loader for the program.

My point is just write in Assembly as anything related to Basic has been removed.

[+OLD CS1]

3 hours ago, RXB said:

But then you are not really in BASIC anymore are you?

How so?  MiniMemory and Editor/Assembler allow such access to set VDP registers.  I wrote two games which took advantage of simple assembly routines to do things like load screens set up character sets.  The programs themselves are very much still BASIC.  If you can use text mode from BASIC without it flipping out, still seems like BASIC.

 

Not to discount your point about just writing in assembler.  I do get that point, but everyone has a reason.

[senior_falcon]

Here's some information about using text mode with TI BASIC: (these addresses are from the MG Explorer manual)

The screen will be from v0000 to v03BF. The normal screen for graphics mode is from v0000 to v02FF, so that area can be used with no problems.

v0300-031F  - VDP color table. The first byte is >D0 to turn off all the sprites. The color table is not need in text mode, so this can be overwritten.

v0320-v036F - crunch buffer

v0370             start of character pattern table

I think the two lines above are inaccurate. Using the Classic99 debugger you can see the crunch buffer is much bigger. I input a long line and the crunch buffer went to v0388.

In any case, the VDP roll out area starts at v03C0 and when you run a BASIC program you can see activity starting at v03C0. I think it is safe to say that the crunch buffer is from v0320 to v03BF.

 

Here's the cool thing: the main use for the crunch buffer is when inputting program lines. Once the program is running there seems to be no activity in the crunch buffer because you are not inputting program lines. The only other time I can see anything happening is when you are inputting something to a BASIC program. RUN this program and watch the activity in the crunch buffer:

10 INPUT A$

20 PRINT A$

30 GOTO 10

The crunch buffer should be available to a running BASIC program as long as you don't use INPUT. Since it is set up for a 32 column screen, INPUT would be of no use in a 40 column text mode screen.

So the screen from v0000 to v03DF can be used for your text mode display and that just happens to be exactly the size required.

 

You would need some assembly routines to pull this off. At a minumum:

CALL LINK("T40")    to set the text mode registers and clear the screen

CALL LINK("INPUT",ROW,COLUMN,A$)  to replace INPUT

CALL LINK("PRINT",ROW,COLUMN,A$)  to replace PRINT

Finally, you would need an interrupt routine to determine if the program is running. If it stops you need to load the BASIC registers so the screen will be visible. You might be able to figure out how the run flag at >8344 works. (it's not clear to me) Or possible look for a cursor at >8301 to know that the program has broken

[GDMike]

I also used call links from assy in the basics to do like char handling etc.

Its a quick way.

Edited September 24, 2021 by GDMike

[+retroclouds]

10 hours ago, senior_falcon said:

I don't understand why you think assembly support would not work.

 

@Retroclouds: Your reference to using an ISR hook makes me think that by TI BASIC, you mean TI BASIC as implemented by the E/A or MiniMemory cartridge. Are you talking about 32 rows of 32 characters, or 32x80? For what it's worth, BASIC can use a 24x40 screen without interfering with anything important. It is almost as if they designed it that way. I can find the memory map tonight if you are interested in pursuing that.

The manual for MG Explorer has some nice memory maps in the back.

 

What I have in mind is the F18a 30 rows mode of 32 characters. TI Basic works great that way and screen output is as one might expect. The only issue is that by using 30 rows, the crunch buffer becomes visible on screen. So putting anything in that screen area gets overwritten. Probably could get away with the lines 28-30, depending on how long the line is that’s being crunched.

 

From a technical perspective what I like about TI Basic is that everything is in VDP. Yes, it’s slow but cool nonetheless.

So when thinking more about it, VDP space for the SIT should not be an issue.

 

24x40 = 960

30x32 = 960 

[+retroclouds]

9 hours ago, RXB said:

You will find HARD CODED ADDRESS in ROM 0, GROM 0, GROM 1 and GROM 2.

And ISR Hook is used to override this problem in many utilities that change these address.

I prefer to just fix the issue instead of circumventing it.

I do think a updated ROM 0, GROM 0, GROM 1 and GROM 2 is due.

As far as I know you cannot override ROM0,GROM1,GROM2 with the final grom cartridge. 

So I guess that would be out of the question and only leaves the ISR route.

Only other possibility I can think of is introducing a new call in TI Basic that does the necessary setup.

Guess that won’t fly because setup of VDP memory would be a one time thing.

[+retroclouds]

13 hours ago, mizapf said:

Have a look at Heiner Martin's TI INTERN. We should even have the PDF somewhere.

Thanks for pointing that out. I actually have a copy of TI INTERN at home. Didn’t think about that.

[speccery]

I don't want to take the thread off topic, but the StrangeCart board I am working on can override GROMs. There are other cartridges which can do the same, and that would enable making some "permanent" changes in the GROMs (for as long as the board is plugged in and in the appropriate config). If it's a matter of changing a few bytes in GROM to make more space for the screen, that is easy to do. I have developed some TI Basic extensions for this board, using mini memory ROM and GROM content as the basis.

[Asmusr]

11 hours ago, retroclouds said:

So I guess that would be out of the question and only leaves the ISR route.

Your idea of an area below the normal TI-BASIC area (for a menu to access stuff in your editor, I guess?) sounds really cool, but I'm not sure I understand how an ISR to move the crunch buffer would work?

 

[+retroclouds]

1 hour ago, Asmusr said:

Your idea of an area below the normal TI-BASIC area (for a menu to access stuff in your editor, I guess?) sounds really cool, but I'm not sure I understand how an ISR to move the crunch buffer would work?

 

To be honest, I don’t eather. But I see the ISR as a vehicle to manipulate VDP and scratchpad at the right moment so that the basic interpreter does stuff in a slightly different way. Not sure if this is even going to work, but that’s part of the fun.

[+RXB]

13 hours ago, retroclouds said:

As far as I know you cannot override ROM0,GROM1,GROM2 with the final grom cartridge. 

So I guess that would be out of the question and only leaves the ISR route.

Only other possibility I can think of is introducing a new call in TI Basic that does the necessary setup.

Guess that won’t fly because setup of VDP memory would be a one time thing.

So who was talking about FinalGrom?

We had SOB (Son of Board) that replaced GROM 0 GROM 1 and GROM 2 so that is doable and ROM 0 could be updated.

Not like we have not added chips to the TI99/4A or replaced them!

 

Edited September 24, 2021 by RXB
missing text

[Asmusr]

1 hour ago, retroclouds said:

To be honest, I don’t eather. But I see the ISR as a vehicle to manipulate VDP and scratchpad at the right moment so that the basic interpreter does stuff in a slightly different way. Not sure if this is even going to work, but that’s part of the fun.

If you just need a few lines to display your info, maybe you could cover the first lines with sprites? Since you would be depending on the F18A, you could fill the entire row with sprites.

[Asmusr]

Further on the dependence on the F18A, you could add a horizontal scanline handler that changes the name table when it reached a certain scan line and changes it back again when the last line is reached.

[+retroclouds]

1 hour ago, RXB said:

So who was talking about FinalGrom?

We had SOB (Son of Board) that replaced GROM 0 GROM 1 and GROM 2 so that is doable and ROM 0 could be updated.

Not like we have not added chips to the TI99/4A or replaced them!

 

I am. The way to distribute my software is via the FinalGrom.

The fact that I have a GRAM kracker and with that the possibility to override the GROMs doesn’t help me.

There are sufficient FinalGROMs out there and they are still available. Something not to be said about the GRAM kracker for example.

 

Having said that, with the strangecart on the horizon it may become a future option again. But it’s not there (yet).

 

 

Edited September 24, 2021 by retroclouds
strangecart

[+retroclouds]

33 minutes ago, Asmusr said:

If you just need a few lines to display your info, maybe you could cover the first lines with sprites? Since you would be depending on the F18A, you could fill the entire row with sprites.

Briefly thought about that. Also thought about using the F18a’s 2nd nametable to overlay on top of lines 25-30.

Not sure if that would be even possible.

 

 

Edited September 24, 2021 by retroclouds

[+retroclouds]

21 minutes ago, Asmusr said:

Further on the dependence on the F18A, you could add a horizontal scanline handler that changes the name table when it reached a certain scan line and changes it back again when the last line is reached.

That is a great idea I want to take a further look at. Thanks for pointing that out.

[+FarmerPotato]

5 hours ago, Asmusr said:

Further on the dependence on the F18A, you could add a horizontal scanline handler that changes the name table when it reached a certain scan line and changes it back again when the last line is reached.

That is an awesome idea. 
 

It got me thinking. by changing the horizontal scroll register, you could get different (parallax) scrolling in top and bottom regions of the screen. With two screen layers you could have FG,BG, and sky. 

[Asmusr]

16 hours ago, FarmerPotato said:

It got me thinking. by changing the horizontal scroll register, you could get different (parallax) scrolling in top and bottom regions of the screen. With two screen layers you could have FG,BG, and sky. 

Absolutely. With the F18A it is possible to scroll each scanline of each of the two tile layers independently.