TI994W emulator problem

[HOME AUTOMATION]

1 hour ago, Tursi said:

Invalid opcodes use six cycles...

D'oh!

Why didn't I think of that...

[F.G. Kaal]

16 hours ago, fabrice montupet said:

It works for you? This is beyond me.
I have precised that I use TMS9918 mode just in case where you would ask to me.  I use the original ROM /GROM TI-99/4A files (those you give with the emulator) and TI Extended Basic.
I have made the same test today and I notice again a cyan screen. Do you have made the test several times?

I had no intention to ask you to use the TMS9918 mode. The code for both the TMS9918 and VDP9938 is the same. The speed of the emulator is no parameter in those functions. Yes ... I did the test several times in different modes ... I only see black in front of my eyes, also when the 80 column DSR is loaded. I don't know what is happening on your side.

 

Edited October 29, 2021 by F.G. Kaal

[fabrice montupet]

We will end to find an explanation ?

When I don't launch XB256, I always get a black screen. It is only when I use XB256 that the problem appears.
I use the TI Extended Basic module, but I use also XB256 when I program (as I said it in a previous message).

Which version of XB256 you use?

[F.G. Kaal]

11 hours ago, fabrice montupet said:

We will end to find an explanation ?

When I don't launch XB256, I always get a black screen. It is only when I use XB256 that the problem appears.
I use the TI Extended Basic module, but I use also XB256 when I program (as I said it in a previous message).

Which version of XB256 you use?

I have XB256 version 2.8 of 2021-08-15 downloaded recently. I am new to this stuff and I have not used it yet because I don't know how. I am still in the stage of figuring out how to use this with the Ti994w emulator.

If you can post a ZIP of the files you are using and the piece of Ti994w.ini to configure it that would be very helpfull. Then I can do what you are doing and figure out what is going wrong.

 

 

[fabrice montupet]

Here is it ?

http://www.ti99.com/misc/Ti994w-XB256.zip

The zip file contains ti994w emulator version that I use, with "Jewel" XB256 in DSK1.

 

EDIT: At the startup screen of XB256, I noticed that sometimes I have to press several times the ENTER key to start  Extended Basic with XB256 (the fist choice in the menu) .  This never annoyed me, but it's  strange.

 

Edited October 30, 2021 by fabrice montupet

[F.G. Kaal]

7 hours ago, fabrice montupet said:

Here is it ?

http://www.ti99.com/misc/Ti994w-XB256.zip

The zip file contains ti994w emulator version that I use, with "Jewel" XB256 in DSK1.

 

EDIT: At the startup screen of XB256, I noticed that sometimes I have to press several times the ENTER key to start  Extended Basic with XB256 (the fist choice in the menu) .  This never annoyed me, but it's  strange.

 

Thanks ... and now I understand what you are doing. I found a big XB256 GPL module thing XB28GEM_8.BIN and XB28GEM_G.BIN and I was examining this but this is much to big of a GPL module for TI994w.

 

Anyway:

A played with this little program in XB256 just to see what is happening.

100 CALL SCREEN(2)            
110 CALL COLOR(2,5,6)         
120 GOTO 120                  

 

You can it al see happening when examining the VDP debug window and I did not need the "use all free CPU time" for this.

 

In extended basic the value of VDP R7= >07 foreground color transparant and background color cyan

 

In XB256 the value of VDP R7= >1E forground color black and background color gray (could have been >0E here)

 

XB256 has an user interrupt routine, vector at >83C4 pointing to >26CA. This routine is changing the default background color cyan to gray.

 

CALL SCREEN changes the value of R7 ... and so is that user interrupt routine.

 

Seems that the interrupt routine here is sometimes interfering at the precise moment the basic programming is starting. Sometimes I see black and sometimes I see cyan as the background color with the corresponding values in VDP R7.

 

This is not something the Ti994w emulator is doing by itself it is al done by the basic program and user interrupt routine.

I don't have the source code of XB256 so I don't know what that code is doing and checking the moment the basic program starts to run. The trick here is that that interrupt routine must synchronized with the moment the programmer types RUN

In short, it is a timing problem.

 

***more info ***

The interrupt routine is checking address >8344, this is the RUN flag. >00 is edit mode >FF is run.

If this flag is >00 the interrupt routine changes the screen color to gray.

If this flag is >FF the interrupt routine changes the screen color to cyan.

Unfortunetly the CALL SCREEN(2) has allready been executed.

Doing a CALL SCREEN twice in this case seems to work better

 

100 CALL SCREEN(2)            <- or use some other little time consuming instruction that also needs to be done
110 CALL SCREEN(2)            
120 CALL COLOR(2,5,6)         
130 GOTO 130 

 

 

 

Also the extra enters keys to press; al the key presses are display in the debug window so these are registered and passed to the emulator but only at the second or third or fourth key press extended basic starts. Depends on how that little menu is checking key presses.

 

 

 

 

 

Edited October 30, 2021 by F.G. Kaal

[fabrice montupet]

Thank you for your investigation.  
Happy to see that you've encountered the color problem. Maybe you'll encounter CALL SOUND problems too? ...I hope!  ^_^

I have never noticed them using Classic99, even the keypress problem .

[F.G. Kaal]

On 10/30/2021 at 11:51 PM, fabrice montupet said:

Thank you for your investigation.  
Happy to see that you've encountered the color problem. Maybe you'll encounter CALL SOUND problems too? ...I hope!  ^_^

I have never noticed them using Classic99, even the keypress problem .

I think I have the CALL SOUND problem solved.

Ti994w-v62c.zip

 

I found a piece of C-code that did the same thing with the sound list as what the TI99 interrupt routine does. This was still from the time (more then 10 years ago) when I started this emulator and not everything was working quit right but I forgot about this code and why it was there. I removed this C-code and now call sound is working fine with XB256. In the proces I also saw one line that simulated the VDP interrupt. I wondered last week why that interrupt counter was still incrementing while the emulator was halted ... now I now ?

 

with CALL KEY there is something strange going on. This is still under investigation.

I am using this little piece of program:

100 CALL KEY(0,K,S)
110 IF S=0 THEN 100
120 PRINT K;
130 GOTO 100

 

and I notice that in TI-Basic, Extended Basic and XB256 the [enter] key is missed 3 of the 4 times when it is pressed and only when using CALL KEY. All the other keys work fine.

The [enter] key is also the only key that does not have the repeat flag set (S=-1 in this case). I am trying to follow the code from the book TI-intern from Heiner Martin to find out why the [enter] key is such a special case. It is not treated differently in Ti994w.

 

 

[fabrice montupet]

Great work! Thank you Fred. This new version has passed all my CALL SOUND tests successfully, I'm so happy ?

 

[fabrice montupet]

I would like to affine some color rendering, is there a way to modify the palette color values?

[F.G. Kaal]

On 11/6/2021 at 4:28 PM, fabrice montupet said:

I would like to affine some color rendering, is there a way to modify the palette color values?

Not yet. Must add some code if you really want this

 

[fabrice montupet]

This request is really minor,  answer to it just if you want and if you have some time to spare. Your emulator is already really great ?

[F.G. Kaal]

After a very long investigation I found out why you have to press enter a few times before a basic program continues when using CALL KEY.

 

I found out that this problem only occurs when doing a CALL KEY() and not with INPUT or LINPUT or ACCEPT. This problem also only occurs when using the PC keyboard option and not with the new TI keyboard option of Ti994w. If this was a general problem I would have noticed this when developing DU2K, DM2K etc.

 

I was using this little test program:

 

100 CALL KEY(0,K,S)
110 IF S=0 THEN 100
120 PRINT A;S;K
130 A=A+1
140 GOTO 100

 

and the problem occurs in both TI BASIC and TI Extended Basic and not only with the enter key, but also with the '=' and the space key.

 

Did some extensive debugging again yesterday afternoon and found out that the keyboard scan routine scans keyboard line 5, then 4, then 3, then 2, then 1 and then 0 and again line 0 a few times and then line 5 etc.

 

The array below shows what keys are on the different keyboard lines:

 

// Keyboard

BYTE CRU_KEYS[8][8]= {
    /* 0 */            {'=', ' ',  13,  0, TIMK_FUNC, TIMK_SHIFT, TIMK_CTRL, 0},
    /* 1 */            {'.', 'L', 'O', '9', '2', 'S', 'W', 'X'},
    /* 2 */            {',', 'K', 'I', '8', '3', 'D', 'E', 'C'},
    /* 3 */            {'M', 'J', 'U', '7', '4', 'F', 'R', 'V'},
    /* 4 */            {'N', 'H', 'Y', '6', '5', 'G', 'T', 'B'},
    /* 5 */            {'/', ';', 'P', '0', '1', 'A', 'Q', 'Z'},
    /* 6 Joyst1 */    {TI_JSFIRE, TI_JSLEFT, TI_JSRIGHT, TI_JSDOWN, TI_JSUP,0,0},
    /* 7 Joyst2 */    {TI_JSFIRE, TI_JSLEFT, TI_JSRIGHT, TI_JSDOWN, TI_JSUP,0,0}
};

 

 

I came to the conclusion that this must be the FCTN-4 check that is executed in both TI Basic and Extended Basic and this is eating up any keyboard key on line 0. This can be check with Ti994w becasue enter, space and '=' not always give a value of -1 (same key as priveous key) for the S variable.

 

The PC keyboard option of Ti994w is placing the pressed key code in a key buffer waiting for the keyboard scan function to pic this op and also clearing that buffer in the process, but now that buffer is also cleared by the FCTN-4 check from basic (and I suppose also by the FCTN-4 check build into the RS232 DSR).

 

Because Ti994w is executing TI code so fast I can't use (yet) the CRU bits at this place because as is done with the new added TI- keyboard option because the (TI) keyboard autorepeat function comes in action very quickly.

 

Conclusion:

The PC-keyboard option of TI994w has a little inconvenience in basic, don't know how to fix that yet.

The TI-keyboard option of TI994w needs some synchronisation with the real world (the user).

 

Maybe I create some mix of these two keyboard functions ... this idea just popped up

 

 

[fabrice montupet]

Now, we know where is the Enter Key problem, thank you for your investigation and the details ?
The problem is not annoying and, for the moment, I prefer to use the "PC keyboard" option, very convenient it offers a very quick keystroke with my french PC Keyboard. I really like this option and I can't imagine using TI keyboard (or US) layout when I use an emulator.

[F.G. Kaal]

Small work arround; when row 0 is scanned then the key buffer is only cleared when CPU address >8375 (key ascii code) is not >FF and not >00.

This means that the KSCAN is scanning the keyboard and not some other scan function that only checks a few keys.

Please notify me if you discover something odd with this new feature.

 

BTW: fctn-4 is a special case in TI994w; this key function has the highest priority and can even override a previous key press.

 

 

Ti994w62c.zip

 

[fabrice montupet]

Yeah! That works! Thank you Fred!

[F.G. Kaal]

And because it was a rainy morning I added a color dialog box. See menu Options / Define colors

?

 

There are two buttons in the dialog:

Reset - Resets to the previous defined colors

Default - Resets to the original Ti994w colors

 

 

 

Ti994w62c.zip

[fabrice montupet]

I definitely like rainy days now ?

Thank you Fred. Now the color displayed perfectly match with the ones of my Sony PVM monitors.
I don't know if you have planed some other features or upgrades for your emulator. All I can say is that it now meets all my expectations.
You made a really good job Fred. Thank you very much, again.

[F.G. Kaal]

16 hours ago, fabrice montupet said:

I definitely like rainy days now ?

Thank you Fred. Now the color displayed perfectly match with the ones of my Sony PVM monitors.
I don't know if you have planed some other features or upgrades for your emulator. All I can say is that it now meets all my expectations.
You made a really good job Fred. Thank you very much, again.

Thank you ?

 

While trying to find the CALL KEY problem I could single step through GPL code but could not see what was happening or what changed.

Now adding some more debug texts for GPL code like I had did for assembler code so that I immediatelly can see what changed and if a jump is taken or not etc.

 

 

[fabrice montupet]

Maybe an improvement could be added.

Your emulator was developed at a time where the 1024x768 resolution was the common one. This is now the lowest of the lowest that is used on computers. For example, my main monitor on my dual screen computer displays 2560x1440 pixels so ti994w runs in a little window. So, I disabled the fixed size option and stretched the window to an higher size. But it's not easy to keep the precise ratio of the 99/4A display.

So, do you think that it could be added (at your choice):
- A  new "x4" (or more) size displaying for example 1152x864 or 1280x960 resolution (so keeping the initial 4:3 ratio)
- The way to lock the horizontal/vertical stretching (optional).  This could permit to people to increase the emulator window to any size of ones choice keep the 4:3 ratio.
Just a though ?

[fabrice montupet]

I forgot to tell that, of course, to change the size of the emulator window, it is possible to modify the .ini file but I think that it is less practical if one often change the resolution of the window (for example, during the development of a program where it is necessary to use / swap to many programs/tools).

Edited November 18, 2021 by fabrice montupet

[F.G. Kaal]

On 11/18/2021 at 10:34 PM, fabrice montupet said:

Maybe an improvement could be added.

Your emulator was developed at a time where the 1024x768 resolution was the common one. This is now the lowest of the lowest that is used on computers. For example, my main monitor on my dual screen computer displays 2560x1440 pixels so ti994w runs in a little window. So, I disabled the fixed size option and stretched the window to an higher size. But it's not easy to keep the precise ratio of the 99/4A display.

So, do you think that it could be added (at your choice):
- A  new "x4" (or more) size displaying for example 1152x864 or 1280x960 resolution (so keeping the initial 4:3 ratio)
- The way to lock the horizontal/vertical stretching (optional).  This could permit to people to increase the emulator window to any size of ones choice keep the 4:3 ratio.
Just a though ?

Was working on the GPL debug code but I got confused and it is difficult to test what I think a source and destination address is and what the GPL interpreter uses as source and destination address. I need much more time for this.

 

So I added a "Preserve 4:3 ratio"  menu option for the VDP display instead.

Also this was more difficult then I thought it would be, but here you have it ... black bars left and right when maximized and the width of the window is calculated from the height to preserve the 4:3 ratio. Resize only works nice with this option when altering the height of the window (for now).

 

 

 

Ti994w62c.zip

[fabrice montupet]

Thanks Fred! And these black bars when maximized are great! You have done more than I expected. You have made so much modifications and upgrades since the beginning of this thread that I felt awkward to ask more.

At this stage, I am fulfilled!

[fabrice montupet]

A sound problem subsist. In the example, I step 100 by 100 to go quickly to the problem.

10 FOR T=110 TO 44733 STEP 100 :: CALL SOUND(-1,T,0) :: PRINT T :: NEXT T

The frequency is not growing up higher than about 5000. Above, the emulator is playing the same frequency.
 

 

[F.G. Kaal]

On 11/27/2021 at 12:32 PM, fabrice montupet said:

A sound problem subsist. In the example, I step 100 by 100 to go quickly to the problem.

10 FOR T=110 TO 44733 STEP 100 :: CALL SOUND(-1,T,0) :: PRINT T :: NEXT T

The frequency is not growing up higher than about 5000. Above, the emulator is playing the same frequency.
 

 

I will check this later (in near future)

I'm still very busy re-arranging the output texts of GPL code while single stepping through this code.

Ralph Benzinger's XDT99 tools are very helpful with this task. Found some improvements (or bugs) in my code that can explain the endless loop while disassembling the FMT code