Detecting Extended BASICs

[ralphb]

Do you know of any way to detect programatically if Extended BASIC or one of its derivatives is inserted in the cartridge port, either at startup or after the command line has shown up? Checking for certain bytes in the ROM/GROM space seems a little too brittle to me.

 

The only sign of Extended BASIC I know of is >8345, which contains some flags for XB. But since TI BASIC doesn't use this location at all, and thus may contain a random value, that address is useless.

 

Maybe you can tell from the program space or any data structures in VDP RAM?

 

[apersson850]

Why is looking for some identification in the module itself brittle? To me, that sounds about as rock solid a method as any could be.

[blackbox]

Use the command line or Extended Basic program line: CALL VERSION(A) -

throws an error if no Extended Basic module and you are in TI Basic, else A is set to a number the packager thought fit- in one third party case it fills the screen with text but normally A is set to a value eg 100, 110, 120 etc.

 

 

When you say "programatically" - using what language? And what other modules could you have in place? 32k ram in place?.... If there is a disk drive, place an Extended Basic program onto the disk and call it LOAD- either a generic cataloguer program or something as simple as:

100 PRINT "EXTENDED BASIC READY" and the Extended Basic auto-load feature will help you.

 

s

[RXB]

Type: CALL VERSION(A)

 

RXB most recent Cart returns 2015 for A.

 

Next version released will be 2019 for A.

Edited January 30, 2019 by RXB

[kl99]

I assume Ralph means programmatically from the DSR that he is writing for SDD99.

 

Do you want to know if XB is in the cartridge port or the active language?

You can still call TI BASIC with XB being in the cartridge port.

 

If you only want to know whether it is plugged in, then check for the GROM Header for the Program name.

 

If you want to know whether XB is active, it might help to know whether this mechanism has only to be checked at a specific time during the init, or whenever the DSR is called?

Meaning can you cache the value somewhere?

[kl99]

from the Basic Interpreter Design Specification:

CPU Ram:

>8345 unassigned

>8388 FLAG ... described as "Error flag bits."

 

from the XB (Product 359) Basic Interpreter Design Specification:

CPU Ram:

>8345 FLAG ... described as "General flag byte."

>8388 unassigned

 

You could trigger some action that causes a change to FLAG.

Like checking the current AUTO NUM status and toggling it to trigger the Auto Num bit switching in the FLAG Byte.

If you see the bit changing in >8345, you are in XB or a XB variant.

If you see the bit changing in >8388, you are in TI Basic.

After your identification toggle it again to restore the memory state as before.

 

At least when using the pure command line (not programmatically), this approach just worked in Classic99.

Now the question is how to toggle Auto Num programmatically

 

Another approach I could think of is using the condition of SDD99 that you always run XB with memory expansion, so it will store numerical variables in expansion ram in contrast to TI Basic.

So:

1. check for the non-existance of variable RALPHB

2. assign Value 1 to variable RALPHB

3. check where the variable got stored by going the path from the CPU pointers.

4. if you end up in CPU Ram you run XB, if you end up in VDP Ram, you run TIB.

4. remove variable RALPHB

[+TheBF]

Could you just examine addresses in the cartridge port space?

 

I can see things with CALL PEEK in XB that of course are not there with CALL PEEK from E/A cartridge.

 

Of course you need CALL PEEK from somewhere to do that.

[+retroclouds]

I would do a CRC check on the rom space.

[sometimes99er]

I would do a CRC check on the rom space.

 

Ah yes. That should potentially also identify different versions of games - even different hacks.

 

[ralphb]

Thanks for all the suggestions. Yes, this is about the SDD 99. Supporting Extended BASIC is trivial, but I need to know when I'm actually called from XB.

 

The problem with checking a few bytes to identify, say, TI Extended BASIC (PHM3026), would likely fail with RXB, Mechatronics XB, or Super XB. And while it's possible that those might be incompatible anyway, I don't like to rule them out upfront.

 

Like Philip suggested, I could create a "database" of all known bytes, and I don't even need to CRC the entire file. Some people might have patched the entry name, like I did for XB V1.00 for the FinalGROM, and then the CRC would be bad.

 

I also could use CALL VERSION. Even though I couldn't type it, I could still check for the existence of that subprogram. That would be easy!

 

But there's still the problem that Klaus mentioned, about XB present, but BASIC selected. I think checking certain memory areas would work best here. Instead of creating and checking for a variable, it might suffice to look at certain pointers, e.g., the pointer to the symbol table now pointing into RAM instead of VDP RAM. Does anybody know how Extended BASIC finds and navigates its programs and variables (Value stack, PAB chain, String space, Symbol table, Line number table, Statement list), and whether there's a notable difference?

 

Also, do we have the (ideally commented) source code to Extended BASIC?

[apersson850]

But the problem with looking at a pointer is that a pointer, in this world, contains a number in the range 0 - 65535. Any program could set any word in memory to any content.

If a pointer is used, it's frequently because the target pointed to could be in different places. At least within a range of addresses. If it's fixed, it can usually be addressed in simpler ways than going via a pointer. But if a range of values are possible, then the probability that some completely different program happens to set that memory cell to a value that looks like a valid pointer increases by the size of the valid range.

Perhaps a combination of "module present" and "certain values in memory" is needed?

[+9640News]

Is there a pointer in Extended Basic that points to the filename "DSK1.LOAD", or perhaps something residual in memory somewhere that indicated Extended Basic had been selected and DSK1.LOAD had attempted to be loaded?

 

If "DSK1.LOAD" had been loaded, and then it told another program to RUN, then that may defeat looking for DSK1.LOAD. Perhaps I am killing my own idea, but was there a mod somewhere that holding the space bar down, bypassed an attempt tl load DSK1.LOAD?

 

Beery

[+TheBF]

After reading the complexity of what should be simple I find myself thinking about Chuck Moore who said something like:

 

"I notice people like to create a generalized solution, but I have never found the generalized problem."

 

Perhaps limiting the scope for now is a way forward. ?

 

Morning coffee does this to me.

[ralphb]

But the problem with looking at a pointer is that a pointer, in this world, contains a number in the range 0 - 65535. Any program could set any word in memory to any content.

If a pointer is used, it's frequently because the target pointed to could be in different places. At least within a range of addresses. If it's fixed, it can usually be addressed in simpler ways than going via a pointer. But if a range of values are possible, then the probability that some completely different program happens to set that memory cell to a value that looks like a valid pointer increases by the size of the valid range.

Perhaps a combination of "module present" and "certain values in memory" is needed?

 

I'm not sure I understand your point entirely, but I was thinking of a pointer that is valid in both worlds, and that would point to the same things, but those things would be located apart.

 

For a made up(!) example, the highest free VDP memory pointer >8370 could be >3800 for BASIC, but >37F0 for Extended BASIC. Klaus mentioned numerical variables located in CPU memory instead of VDP memory for XB, so maybe that would do?

[ralphb]

Is there a pointer in Extended Basic that points to the filename "DSK1.LOAD", or perhaps something residual in memory somewhere that indicated Extended Basic had been selected and DSK1.LOAD had attempted to be loaded?

 

If "DSK1.LOAD" had been loaded, and then it told another program to RUN, then that may defeat looking for DSK1.LOAD. Perhaps I am killing my own idea, but was there a mod somewhere that holding the space bar down, bypassed an attempt tl load DSK1.LOAD?

 

I really like that! I'll have to check if I can still find that somewhere, probably in the BASIC PABs.

[ralphb]

Yep, that's it! Not where or how I expected it, but in VDP RAM:

 

 

This works for XB, Super XB, Mechatronics XB. I still may need another solution for RXB, but I have to check first. Maybe Rich can suggest something.

 

[RXB]

XB address >8345 is defined as FLAG:

 

>01 autotnumber mode on (Edit mode)

>02 list flag indicated list is being used to list the program in memory to a device

>08 ignore symbol table search

>04 is CONTINUE after a break or interruption

>80 is the Program Protection flag

 

There are many others but just wanted to point out that this is not a usable storage place.

[ralphb]

XB address >8345 is defined as FLAG:

 

>01 autotnumber mode on (Edit mode)

>02 list flag indicated list is being used to list the program in memory to a device

>08 ignore symbol table search

>04 is CONTINUE after a break or interruption

>80 is the Program Protection flag

 

There are many others but just wanted to point out that this is not a usable storage place.

 

Thanks, but I had mentioned >8345 in my first post as not working. I cannot tell whether >8345 contains a valid flag in Extended BASIC, or just a random word in BASIC (unless it's an invalid flag combination, but this is random).

[senior_falcon]

If you just want to know whether you are in TI BASIC or in XB the color tables in VDP might be helpful. If I remember right, TI BASIC has the color table at V0300 and XB has it at V0800. You can look with Classic99's debugger to see if that might be useful.

[ralphb]

If you just want to know whether you are in TI BASIC or in XB the color tables in VDP might be helpful. If I remember right, TI BASIC has the color table at V0300 and XB has it at V0800. You can look with Classic99's debugger to see if that might be useful.

 

That's a nice idea! Unfortunately, the VDP registers are write-only, so I could only check for >17 at both addresses. For RXB that would be >F6 or something like that.

[apersson850]

What I meant was that when a DSR is called, you can never rule out that a completely different program has, by coincidence, put a value at a certain address that's the same, or similar, to what Extended BASIC would put there, had it been running.

The remnant of the file name LOAD will probably not exist in memory if Extended BASIC has opened other files, after running, or attempting to run, DSK1.LOAD on startup.

 

But I don't know the circumstances when you expect your DSR to be called, so I may be completely off.

[RXB]

I think the GROM HEADER is best bet to find what cart is loaded:

[0441]               ***********************************************************
[0442]               *                        GROM HEADER
[0443]               ***********************************************************
[0444]                      GROM >6000
[0445]                      AORG 0
[0446] 6000 AA,12           DATA >AA12      * VALID GROM / VERSION 18
[0447] 6002 01,00           DATA >0100      * (FUTURE EXPANSION)
[0448] 6004 00,00           DATA >0000      * POWER
[0449] 6006 63,3B           DATA XBCART     * PROGRAMS
[0450] 6008 00,00           DATA >0000      * DSR 
[0451] 600A A0,26           DATA LINK1      * CALL
[0452] 600C 00,00           DATA >0000      * INTERUPT
[0453] 600E 00,00           DATA >0000      * BASIC CALL
[0454]               ***********************************************************

At GROM address >6006 will be >633B and that is ALL XB Cartridges including SXB, RXB, GKXB, XB, and XB 2.6 so this will only be seen in XB carts.

 

In XB at VDP at >37D8 you will find >AA >3F >FF >11 >03

 

This is the same for the same Cartridges as mentioned above, but in TI Basic they will be >00 >00 >00 >00 >00

 

I think this solves you problem of what Cartridge is loaded vs any other or TI Basic.

 

Also at VDP address >0821 all XB carts load DSK1.LOAD even RXB.

You can test this with Classic99 easy just use debugger to look at >0821 VDP and see what drive and program was loaded.

 

On my real iron TI99/4A EXAMPLE: OLD SCS1.MYPRGMS.RXB2019.SWAP

 

At >0821 is SCS1.MYPRGMS.RXB2019.SWAP

Edited January 31, 2019 by RXB

[ralphb]

Thank you Rich, that will work beautifully, especially those pointers to VDP RAM!

[ralphb]

What I meant was that when a DSR is called, you can never rule out that a completely different program has, by coincidence, put a value at a certain address that's the same, or similar, to what Extended BASIC would put there, had it been running.

The remnant of the file name LOAD will probably not exist in memory if Extended BASIC has opened other files, after running, or attempting to run, DSK1.LOAD on startup.

 

But I don't know the circumstances when you expect your DSR to be called, so I may be completely off.

 

Oh, I see now. That's definitely true. That why I was thinking about pointers that (Extended) BASIC controls, so that it couldn't be overwritten by a program. (And even then we have the problem of using assembly programs in Extended BASIC, which could do anything.)

 

But I just love all the creative ways you guys come up with!

[+Lee Stewart]

...

In XB at VDP at >37D8 you will find >AA >3F >FF >11 >03

 

Thank you Rich, that will work beautifully, especially those pointers to VDP RAM!

 

The VRAM info depends on disk controllers. For instance, if a CF7+ or nanoPEB is installed, >37D8 will definitely NOT have those values. They will have moved down 8 bytes. At least one disk controller does not use VRAM buffers, so, even checking >8370 in scratchpad RAM for top of available VRAM will not help.

 

...lee