TI994W emulator problem

[senior_falcon]

4 hours ago, F.G. Kaal said:

Writting >FFFF to address >8802 to change a register (both >8000 for writing to register and >4000 for writing VDP RAM are set) tries to change a register that doesn't exist. Emulator gives a warning  ones and continues.

 

Writing >FFFF to address >8C02 (VDPWA) to setup an address to write data  (both the >8000 bit for writing to register and >4000 bit for writing VDP RAM are set) changes the VDP address to >3FFF. Emulator gives a warning  ones and continues.

If data is read instead of written then the Emulator gives a warning but continues. This is just messy programming.

 

Writing an address with >4000 bit reset to >8C02 (VDPWA) to read a value but a value is written instead then Emulator gives a warning but continues. This is just messy programming.

 

Writing an address with >4000 set to >8C02 (VDPWA) to write a value but a value is read instead then Emulator gives a warning but continues. This is just messy programming. However, the real VDP does a prefetch when data is about to be read and that prefetch is not done in this case and can cause a wrong value to be read.

I am confused. Are you saying that XB256 does the above?

[fabrice montupet]

I still tried today same problem playing CALL SOUND(100,6000,0)

Here is a video showing the problem and the DEBUG.TEXT file:

http://www.ti99.com/misc/IMG_2090.MOV

http://www.ti99.com/misc/DEBUG.TXT

 

[SteveB]

Well, I had the same issue with my XB256 game-program, hanging on the first CALL SOUND, but the latest release fixed it and everything works now for me.

[fabrice montupet]

Oh! After numerous tests, I noticed that the problem seems to not be the frequency that causes the garbage noise & sounds but the duration. After 25 minutes testing different duration values, all CALL SOUND (note or noise) including a duration below the value 34 were played perfectly with no erratic sound after. But if I use the value 34 and higher, the CALL SOUND cause problems.

EDIT:

Important precision: If I do a NEW and execute a simple XB256 program just containing a CALL SOUND with a duration > 33, it works. If I insert a CALL SOUND with a duration > 33 in my XB256 program (It only  uses CALL LINK "DELAY" and  "DISPLY" and uses SCREEN1 XB256 features) , the problem appears.

...My program is haunted! ?

Edited October 26, 2021 by fabrice montupet

[senior_falcon]

Before I invest a lot of time tracking down a problem that may not even be a problem, I need to know whether this behavior happens when using Classic99 or Win994a or a real TI99.

[fabrice montupet]

This problem doesn't interfere the programming of my XB256 program, I just have to pay attention to not exceed the value 33 in the duration of a tone/noise. When it will be corrected, I just will have to put the right duration ?

[HOME AUTOMATION]

Sounds like:

 

              ...Time for a Pentium 9900 processor

 

             

[senior_falcon]

2 hours ago, fabrice montupet said:

This problem doesn't interfere the programming of my XB256 program, I just have to pay attention to not exceed the value 33 in the duration of a tone/noise. When it will be corrected, I just will have to put the right duration ?

Without more information, this will never be corrected. Again, does this problem happen with Classic99 or a real TI99???

I entered this:

10 CALL SOUND(1000,220,0)
20 CALL SOUND(1000,440,0)

and it runs properly under XB256 using both Classic99 and a real TI99

I added another line:

15 CALL SOUND(1000,330,0) and again it runs properly under XB256 with both Classic99 and a real TI99

I am unable to test TI994W. Does this cause the problem for you using TI994W?

 

[F.G. Kaal]

19 hours ago, senior_falcon said:

I am confused. Are you saying that XB256 does the above?

Don't get confused ...  This is just a description of what the Ti994w emulator does when an erroneous value is written to the VDP in order to set a VDP read/write address or trying to change a VDP register. An error message is printed in the debug window and the Ti994w emulator is making the best of it. The programmer/user must do something with this

 

The original problem was that the game ALIENKEY-X was writing a value of >FFFF to the VDP. The question is: Is this just an error in the game ALIENKEY-X (the problem lays then between the backrest and the computer screen) or is it caused by one of the XB256 functions that game is using.

 

And this was the piece of code that was executed when it happened, see addresses >FF44 to >FF4E.

Again; I don't know if this is a programmers error, or an error the programmer should think about (writing to address -1) or that this is caused by a function the programmers is using. The only thing I could fix is that the Ti994w emulator is doing it's best to continue to run the faulty program and not stop functioning.

 

Spoiler

>F20A: >070F               SETO   R15
>F20C: >0420               BLWP   @>E518  
>F210: >C160               MOV    @>83AA ,R05
>F214: >1303               JEQ    >03                       [ to PC:>F21C ]
>F216: >C800               MOV    R00,@>FAAE 
>F21A: >1002               JMP    >02                       [ to PC:>F220 ]
>F21C: >C800               MOV    R00,@>FADA 
>F220: >0460               B      @>E836  
>F224: >04C0               CLR    R00
>F226: >0201 >8000         LI     R01,>8000
>F22A: >0202 >0300         LI     R02,>0300
>F22E: >06A0               BL     @>E4EA  
>F232: >1002               JMP    >02                       [ to PC:>F238 ]
>F234: >D801               MOVB   R01,@>8C00 VDPWD
>F238: >0602               DEC    R02
>F23A: >16FC               JNE    >FC                       [ to PC:>F234 ]
>F23C: >0460               B      @>E836  
>F240: >06A0               BL     @>E894  
>F244: >C014               MOV    *R04,R00            <--- R4 = >D928 == >0001
>F246: >C095               MOV    *R05,R02            <----R5 = >D92A == >0000
>F248: >0600               DEC    R00                 R0 := >0000
>F24A: >0602               DEC    R02                 R2 := >FFFF
>F24C: >0A50               SLA    R00,05              R0 := >0000
>F24E: >A002               A      R02,R00             R0 := >FFFF
>F250: >06C0               SWPB   R00           
>F252: >D800               MOVB   R00,@>8C02 VDPWA
>F256: >06C0               SWPB   R00
>F258: >D800               MOVB   R00,@>8C02 VDPWA
>F25C: >1000               JMP    >00                       [ to PC:>F25E ]
V9938: R63 := >FF (255) ERROR: VDP register number out of range
>F25E: >D060               MOVB   @>8800 VDPRD,R01
>F262: >0221 >A000         AI     R01,>A000

 

Edited October 27, 2021 by F.G. Kaal

[F.G. Kaal]

19 hours ago, fabrice montupet said:

I still tried today same problem playing CALL SOUND(100,6000,0)

Here is a video showing the problem and the DEBUG.TEXT file:

http://www.ti99.com/misc/IMG_2090.MOV

http://www.ti99.com/misc/DEBUG.TXT

 

Hihi ... very interesting.

 

What I meant is to examine the addresses that is used for sound. It is described in the editor assembler manual.

 

Word address >83CC is a pointer to the sound list in VDP (or CPU) ram

Byte address >83FD is a flag (bit >01) to tell the system that the buffer is in VDP ram

Byte address >83CE is a trigger (bit >01) that starts the sound

 

When a call sound is executed these addresses are set.

 

I can imagine that if something is fooling arround with these addresses that some random/garbidge noise is played.

 

You can edit this window by holding the CTRL key and klick on a '-' or a 'name' (left column). A small dialog is opened in which you can enter the thing you want to keep a close eye to.

 

The debug.txt file: Is that a capture when the emulator is doing nothing/not running any program?

The emulator is not writing to the sound addresses by itself ... there must be some TI99 code behind it to do that.

 

 

Or paste this at the correct place in the Ti994w.ini file

 

Spoiler

[WatchToolWindow]
;
; Automatically created
;
left=10
top=10
width=435
height=323
open=1
var00=>83C6  83c6 0122 000a
var01=KBMODE 8374 0122 0002
var02=ASCII  8375 0122 0014
var03=-      0000 0124 000f
var04=-      0000 0141 0010
var05=STATUS 837c 0122 0010
var06=-      0000 0124 0008
var07=>8379  8379 0122 0008
var08=>834A  834a 0144 0008
var09=STACK  838a 0164 0006
var10=-      0000 0124 0008
var11=SoundB 83cc 0124 0006
var12=VdpFlg 83fd 0122 0014
var13=SndTrg 83ce 0122 0007
var14=CDATA  0379 0262 000a
var15=-      0000 0164 0007
var16=-      0000 0164 0004
var17=-      0000 0124 0028
var18=-      0000 0124 0000
var19=-      0000 0124 0028
var20=-      0000 0164 0004
var21=-      0000 0124 0005
var22=-      0000 0162 0014
var23=-      0000 0164 0003
var24=-      0000 0124 000a
var25=-      0000 0464 0010
var26=-      0000 0241 000a
var27=-      0000 0104 0000
var28=-      0000 0104 0000
var29=-      0000 0104 0000
var30=-      0000 0104 0000
var31=-      0000 0104 0000
var32=-      0000 0000 0000

 

 

Edited October 27, 2021 by F.G. Kaal

[fabrice montupet]

17 hours ago, senior_falcon said:

Without more information, this will never be corrected. Again, does this problem happen with Classic99 or a real TI99???

I entered this:

10 CALL SOUND(1000,220,0)
20 CALL SOUND(1000,440,0)

and it runs properly under XB256 using both Classic99 and a real TI99

I added another line:

15 CALL SOUND(1000,330,0) and again it runs properly under XB256 with both Classic99 and a real TI99

I am unable to test TI994W. Does this cause the problem for you using TI994W?

 

If I had seen the problem on the real 99/4A or Classic99, I would not have post my message in this thread that I have created to report problems with the ti994w emulator.

Please, read well my messages. You'll see that I have no problem with CALL SOUND inserted in a simple loop but in my programs that contain XB256 features like CALL LINK DELAY AND DISPLY using the ti994w emulator. I make no conclusion, It is just a behavior noticed. But maybe the CALL SOUND erratic behavior is present just using TI Extended Basic? I don't know. The problem is that all my program use XB256 features so I can't try to reproduce the problem with just Extended Basic running.

Edited October 27, 2021 by fabrice montupet

[fabrice montupet]

An other problem noticed (TMS9918 mode):
 

10 CALL SCREEN(2)
20 GOTO 20

'Use all free CPU time' disabled, I obtain a black screen. Normal ?
'Use all free CPU time' enabled, I obtain a cyan screen...  Why?

 

 

Edited October 27, 2021 by fabrice montupet

[fabrice montupet]

5 hours ago, F.G. Kaal said:

The debug.txt file: Is that a capture when the emulator is doing nothing/not running any program?

The emulator is not writing to the sound addresses by itself ... there must be some TI99 code behind it to do that.

The debug.txt file is the result of what you see (ear) in the video, when I added the value 34 in the duration of a call sound I inserted in my program.

My program contains no other audio code than the CALL SOUND(100,6000,0)

[+Retrospect]

15 hours ago, F.G. Kaal said:

Is this just an error in the game ALIENKEY-X

Hi.  I'm the author of that software.  As far as I know the game shouldn't produce anything strange.  Does the game hang or crash? And if so at what point in the game does this happen?

[senior_falcon]

Fred found an error in the "star wars" scroll code. I was using INC to advance a return address where I should have been using INCT. This never caused trouble with Classic99 and I believe it works on a real TI99 as well. I think the reason is that when an invalid opcode is encountered it is just skipped. Apparently TI994W reports an error instead. (Not saying that's bad, it's just different)

I suppose it is possible that something like this is causing the problem. I will look into it some more.

[F.G. Kaal]

21 hours ago, fabrice montupet said:

The debug.txt file is the result of what you see (ear) in the video, when I added the value 34 in the duration of a call sound I inserted in my program.

My program contains no other audio code than the CALL SOUND(100,6000,0)

Aha ... now I understand, there was a sound here on this side. The volume of my laptop was set to low.

 

As I said a few message back; there must be TI99 code behind it, the emulator is not doing something by it self.

The movie does not tel me yet what is going on because it doesn't show the interesting sound addresses.

See my message #85 of yesterday.

 

And if those strange sounds are playing and you halt the emulator, does the sound continues?

And if the emulator is halted and the souns stopped, what happens when you single step?

What code do you see? On what CPU addresses is that code running?

 

[F.G. Kaal]

12 hours ago, Retrospect said:

Hi.  I'm the author of that software.  As far as I know the game shouldn't produce anything strange.  Does the game hang or crash? And if so at what point in the game does this happen?

The game doesn't crash Stargunner ?. There is a value of >FFFF written to the VDP and that value is illegal because it is both a VDP write address (>3FFF) and a VDP register value >FF for VDP register 63. Both the 9918 and 9938 does not have a register 63.

 

The $65535 question is if that value is caused by the user program (game) or is it caused by some library function the program is using.

 

[F.G. Kaal]

1 hour ago, senior_falcon said:

Fred found an error in the "star wars" scroll code. I was using INC to advance a return address where I should have been using INCT. This never caused trouble with Classic99 and I believe it works on a real TI99 as well. I think the reason is that when an invalid opcode is encountered it is just skipped. Apparently TI994W reports an error instead. (Not saying that's bad, it's just different)

I suppose it is possible that something like this is causing the problem. I will look into it some more.

That is good news senior_falcon. It is also not a problem anymore in Ti994w ... the emulator was just very strict. In the 20 years (or so) that this emulator exists it is the first time I saw something like this strange VDP writings happen, the value >FFFF  sugests that it should have been >0000 (i guess). And it was indeed during scolling in the ALIENKEY game.

 

Somewhere in this stage of the games it happens:

 

 

And this is the log:

Spoiler

V99xx: read  data   VDPRA >4340 (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: read  data   VDPRA >435C (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: read  data   VDPRA >437F (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: read  data   VDPRA >40C1 (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: read  data   VDPRA >40C4 (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: read  data   VDPRA >42F0 (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: VDPWA = >FFFF ERROR: Both bits for writing register and data are set
V9938: R63 := >FF (255) ERROR: VDP register number out of range
V99xx: read  data   VDPRA >FFFF (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: read  data   VDPRA >437F (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: read  data   VDPRA >4348 (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: read  data   VDPRA >437F (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: read  data   VDPRA >436C (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: read  data   VDPRA >4790 (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: read  data   VDPRA >4300 (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: read  data   VDPRA >437F (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: read  data   VDPRA >4340 (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: read  data   VDPRA >478E (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: read  data   VDPRA >437F (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: read  data   VDPRA >437F (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: read  data   VDPRA >437F (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: read  data   VDPRA >42F0 (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: read  data   VDPRA >437F (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: read  data   VDPRA >437F (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: read  data   VDPRA >437F (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: read  data   VDPRA >4344 (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: read  data   VDPRA >40D4 (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: read  data   VDPRA >42F0 (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: read  data   VDPRA >4782 (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: read  data   VDPRA >4302 (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: read  data   VDPRA >42F0 (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: read  data   VDPRA >478E (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: read  data   VDPRA >40C3 (ERROR reading data but bit 0x8000 and/or 0x4000 is set)
V99xx: VDPWA = >FFFF ERROR: Both bits for writing register and data are set
V9938: R63 := >FF (255) ERROR: VDP register number out of range
V99xx: read  data   VDPRA >FFFF (ERROR reading data but bit 0x8000 and/or 0x4000 is set)

 

 

It is not only that a value of >FFFF is written but also that a VDP read address is setup with bit >4000 set. This bit must only be set when setting up a VDP write address. According to the VDP TMS9918 manual there can be a penalty  for doing it incorrect on the real iron. If a VDP read address is setup properly the VDP does a prefetch of the data. If it is done incorrect the prefetch doesn't happen and when the data is read then it is possible the the VDP can't fetch the data in time.

 

The (disassembled) code that is in lomem when using the editor/assembler module is i.e. like this:

Spoiler

* VSBW
VSBW$  BL      @VDPW                    Setup VDP write address
            MOVB  @2(R13),@VDPWD   Write byte
            RTWP
 

 

* VMBW
VMBW$   BL       @VDPW                Setup VDP write address
VMBW$1 MOVB  *R1+,@VDPWD    Write byte
               DEC    R2                        More?
               JNE    VMBW$1               Yes!
               RTWP
 

 

* VSBR
VSBR$  BL       @VDPR                    Setup VDP read address
            MOVB  @VDPRD,@2(R13)   Read byte
            RTWP
 

* VMBR
VMBR$    BL    @VDPR                    Setup VDP read address
VMBR$1  MOVB    @VDPRD,*R1+   Read byte
               DEC    R2                        More?
               JNE    VMBR$1                Yes!
               RTWP
 

 

* VWTR
VWTR$   MOV    *R13,R1                     Get register number and data
              MOVB    @1(R13),@VDPWA   Write data
              ORI    R1,>8000                    Set MSBit for VDP register number
              MOVB    R1,@VDPWA             Write register number
              RTWP

 

* This standard function is doing a bit to much for VSBW and VSBR but it makes the code a few istructions shorter.

* VDP R/W helper
VDPW   LI    R1,>4000                                   Set bit for VDP write address
           JMP    VDP$1
VDPR   CLR    R1                                            No bits to set for VDP read adrress
VDP$1 MOV    *R13,R2                                  Get VDP address
           MOVB    @UTILWS+LR02,@VDPWA      Write LOByte
           SOC    R1,R2                                       Set bits (if any)
           MOVB    R2,@VDPWA                           Write HOByte
           MOV    @2(R13),R1                             Get R1 (byte or buffer address)
           MOV    @4(R13),R2                             Get byte count
           RT

 

Edited October 28, 2021 by F.G. Kaal

[F.G. Kaal]

22 hours ago, fabrice montupet said:

An other problem noticed (TMS9918 mode):
 

10 CALL SCREEN(2)
20 GOTO 20

'Use all free CPU time' disabled, I obtain a black screen. Normal ?
'Use all free CPU time' enabled, I obtain a cyan screen...  Why?

 

 

Sorry ... I only see black screens.

The TMS9918 and V9938 are using the same code. Only if V9938 is enabled the code is using 45 VDP registers and 128Kb VDP RAM and 64Kb extended VDP ram and (almost) all the V9938 goodies build in to that processor.

 

What module are you using?

[fabrice montupet]

18 minutes ago, F.G. Kaal said:

Sorry ... I only see black screens.

The TMS9918 and V9938 are using the same code. Only if V9938 is enabled the code is using 45 VDP registers and 128Kb VDP RAM and 64Kb extended VDP ram and (almost) all the V9938 goodies build in to that processor.

What module are you using?

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?

[+Retrospect]

Fabrice, if you are using XB256 to do these things, it might be worthwhile checking to see if you have the very latest update.  Thats the only advice I can offer here. 

[fabrice montupet]

Thank you for your advice ?

I use the Juwel folder with ti994w.
 

[senior_falcon]

Can someone provide me a copy of ALIENKEY-X.

[+Retrospect]

2 hours ago, senior_falcon said:

Can someone provide me a copy of ALIENKEY-X.

ALIENKEY-X

im not saying its aliens.txt

 

Just in case you need it there's the XB source included.

[Tursi]

12 hours ago, senior_falcon said:

Fred found an error in the "star wars" scroll code. I was using INC to advance a return address where I should have been using INCT. This never caused trouble with Classic99 and I believe it works on a real TI99 as well. I think the reason is that when an invalid opcode is encountered it is just skipped. Apparently TI994W reports an error instead. (Not saying that's bad, it's just different)

Two things about that... 

 

Invalid opcodes use six cycles and do not affect registers or memory.

 

But an odd return address is simply cropped to 15 bits. The 9900 can only express 15 bits of address, so the least significant bit never makes it out to the hardware, including RAM. BigFoot also crashes if you don't handle this correctly.

 

Edited October 29, 2021 by Tursi