Jump to content
IGNORED

TI994W emulator problem


fabrice montupet

Recommended Posts

Okay ... found something that reveals the problem; I found ALIENKEY-X of Retrospect and the sound did stop playing.

Opened the debug window of Ti994w and single stepped a few instructions and saw this:

 

 

SOUND: >89 >2F    Tone 1: Frequency: >2F9 -  761 (146.99 Hz)
SOUND: >90        Tone 1: Volume   : >00  -    0 (-0 dB)
SOUND: >A4 >2F    Tone 2: Frequency: >2F4 -  756 (147.96 Hz)
SOUND: >B0        Tone 2: Volume   : >00  -    0 (-0 dB)
SOUND: >9F        Tone 1: Volume   : >0F  -   15 (off)
SOUND: >BF        Tone 2: Volume   : >0F  -   15 (off)
SOUND: >DF        Tone 3: Volume   : >0F  -   15 (off)
SOUND: >FF        Noise : Volume   : >0F  -   15 (off)

 

Sound stops here, halted the emulator and single stepped through the code and found a forever loop ...


>E60E: >13FD               JEQ    >FD                       [ to PC:>E60A, TRUE { EQ=1 } ]
>E60A: >0580               INC    R00                       [ >9CA1 := >9CA2 ]
>E60C: >D11E               MOVB   *R14,R04                  [ >0058 := >0058 ]
>E60E: >13FD               JEQ    >FD                       [ to PC:>E60A, TRUE { EQ=1 } ]
>E60A: >0580               INC    R00                       [ >9CA2 := >9CA3 ]
>E60C: >D11E               MOVB   *R14,R04                  [ >0058 := >0058 ]
>E60E: >13FD               JEQ    >FD                       [ to PC:>E60A, TRUE { EQ=1 } ]
>E60A: >0580               INC    R00                       [ >9CA3 := >9CA4 ]
>E60C: >D11E               MOVB   *R14,R04                  [ >0058 := >0058 ]
>E60E: >13FD               JEQ    >FD                       [ to PC:>E60A, TRUE { EQ=1 } ]
>E60A: >0580               INC    R00                       [ >9CA4 := >9CA5 ]

 

Register R14 points to address >8800 and register R4 always receives the value >0058.

The most significant byte of R4 is indeed >00 so the big question is "what did the program expected to find here". ;-)

 

 

 

  • Like 1
Link to comment
Share on other sites

Found this code in my VDP emulation:

 

		if ((Vdpwa & VDPWA_D)!=0) //VDPWD
		{
			result=0;
#if 1
			CPrintfX(DBG_VDP, "V99xx: Read  data  VDPWA >%04X = >%02X (ERROR: VDP ADDRESS OUT OF RANGE)", Vdpwa, result);
			if (PUnopint)
			{
				PStep = 1;
				Tms9900_Stat |= TMS9900_HALT;
				CreateDbgToolWindow(MainWindow, MainInstance);
				CpuDialog(MainWindow, MainInstance);
				MessageBox(MainWindow, "ERROR: VDPWA out of range", szAppName, MB_OK | MB_APPLMODAL | MB_ICONERROR | MB_SETFOREGROUND | MB_TOPMOST);
			}
#endif
		}
		else
#endif
		{
			Vdpwax = (ushort) (Vdpwa & ~VDPWACB);

			if (Vdp9938)

Seems that the MOVB *R14 was reading the VDP address >403E.

 

Can not figure out why the test "if ((Vdpwa & VDPWA_D)!=0)" is there and why it is only a problem with XB256.

So it seems that the problems is not with sound but with the VDP implementation.

Played a bit with the "ALIENKEY-X" program and also discovered that the value >FFFF is written to the VDP R/W address somewhere in the code ... maybe this is the source of the above problem but I am not sure yet.

 

For now I disabled the above test because the two most significant bits must be removed from the VDP address anyway (Vdpwax = (ushort) (Vdpwa & ~VDPWACB);) and for now here is an unofficial release of Ti994w version 63c with some new features (copy/paste, keyboard, system speed).

 

enjoy :-)Ti994w61c.zip

 

 

 

  • Like 1
Link to comment
Share on other sites

Thank you Fred.
Here is what I have done: I have duplicated my ti994w folder to make a backup, on the original ti994w folder, I have copied the two files from ti994w61c.zip and launched the emulator

Alas, there's problems:
 When I set 0 CPU delay, the emulator is too much slow.
So I wanted to "Use All Free CPU Time" as I done before (jointly to my decrease PC speed tip explained in one of my previous message) but when I activate  "Use All Free CPU Time" the emulator hangs (like it was paused), I have to disable to see the emulator running again.

For this moment, I have to return to the previous version of the emulator.

 

 

 

Edited by fabrice montupet
Link to comment
Share on other sites

Hi Fabrice, I don't understand your problem.

 

If CPU delay is set to 0 the the emulator is what is was before ... fast.

 

Spoiler

        if (CpuDelayTime)
        {
            GetOpcTime();
            NextOpc(0);
            DelayOpcTime();
        }
        else
        {
            NextOpc(0);
        }

 

 

The function NextOpc(0) means executing the next opcode without (0) disassembling it.

GetOpcTime() stores the current time of the PC since startup.

DelayOpcTime() halts the emulator until the set CPU delay has been expired since the value that has been stored with GetOpcTime.

 

There seems to be a problem now with "use all free CPU time". I don't understand why ... there has been absolutely nothing changed there in that code. Just checked  and to make matters worse; I don't understand that code anymore. ? And it was still functioning normal in the previous unofficial release! This is just another fine mess I got myself into.

 

Better leave this function off / disabled, this has no use when setting a CPU delay because the emulator is then doing nothing as fast as possible eating up a lot of cpu time to check if the set delay time  has been expired. It is even possible that  you have a hard time doing something with another program. This option has no use when playing with the CPU delay time. (I suoppose I disable this option in the menu when a CPU delay time is set).

 

What I want to know is if the range of 0 to 10 us is enough for what you want to do.

 

This version has supposed to be 6.2.c (I made some typos here and there).

 

 

Hopy this helps.

 

 

Link to comment
Share on other sites

56 minutes ago, F.G. Kaal said:

Hi Fabrice, I don't understand your problem.

If CPU delay is set to 0 the the emulator is what is was before ... fast.

When I run your last version for the emulator, setting the value speed to 0 gives the same speed (or seems to give, I have not exactly measured) as a the real computer runs, this is not what I expected.

In fact, I had hopped that the speed gear could be set to 0 to set the emulator as fast  as the emulator runs when "Use all free CPU Time" is enabled, the value 10 could be the lowest speed the emulator could run and between 0 and 10, it would find a value that corresponds to the normal speed of the real computer.

 

So, of course, the "use all free CPU time" option in the menu could be delete as its feature would be realized in the speed gear.

 

Thank your Fred for all the time you allow to me.

Link to comment
Share on other sites

Played a bit with the "ALIENKEY-X" program and also discovered that the value >FFFF is written to the VDP R/W address 

 

Not clear if your code does it, but if the address >FFFF is written to the VDP address register, then this should:

 

- set the VDP address to >3FFF, and not execute a prefetch

- set VDP register 7 to >FF

 

Obviously that's not really a meaningful setting, the source software is probably malfunctioning, but, it's helpful to have the same behavior. :)

 

Classic99 was running slow for Fabrice too... if you figure out what it was, can you let me know? I can fix my side too.

 

  • Like 1
Link to comment
Share on other sites

8 minutes ago, Tursi said:

 

 

 

Not clear if your code does it, but if the address >FFFF is written to the VDP address register, then this should:

 

- set the VDP address to >3FFF, and not execute a prefetch

- set VDP register 7 to >FF

 

Obviously that's not really a meaningful setting, the source software is probably malfunctioning, but, it's helpful to have the same behavior. :)

 

Classic99 was running slow for Fabrice too... if you figure out what it was, can you let me know? I can fix my side too.

 

When I was investigating Fabrice’s problem and had added some debug code to my emulator I found out that the above code came into the part of setting VDP register 63 of a V9938. This VDP “only” has 45 registers.

 

I still want to find the location in the code what does this and let you now if I have found it.

 

  • Like 1
Link to comment
Share on other sites

15 minutes ago, fabrice montupet said:

When I run your last version for the emulator, setting the value speed to 0 gives the same speed (or seems to give, I have not exactly measured) as a the real computer runs, this is not what I expected.

In fact, I had hopped that the speed gear could be set to 0 to set the emulator as fast  as the emulator runs when "Use all free CPU Time" is enabled, the value 10 could be the lowest speed the emulator could run and between 0 and 10, it would find a value that corresponds to the normal speed of the real computer.

 

So, of course, the "use all free CPU time" option in the menu could be delete as its feature would be realized in the speed gear.

 

Thank your Fred for all the time you allow to me.

Fabrice,

0 is no delay (fastest)

10 is maximum delay (slowest)

this delay should be in real micro seconds per TMS9900 instruction but I haven’t found a method yet to measure this. The code I use have a resolution of 100 nano seconds.

 

if you disable the “use all free cpu time” option and set the CPU delay on something between 1 and 10 us  can you find a value that corresponds to the speed of the real iron?

Link to comment
Share on other sites

8 hours ago, Tursi said:

 

 

 

Not clear if your code does it, but if the address >FFFF is written to the VDP address register, then this should:

 

- set the VDP address to >3FFF, and not execute a prefetch

- set VDP register 7 to >FF

 

Obviously that's not really a meaningful setting, the source software is probably malfunctioning, but, it's helpful to have the same behavior. :)

 

Classic99 was running slow for Fabrice too... if you figure out what it was, can you let me know? I can fix my side too.

 

The >FFFF is written from the ALIENKEY program to the VDP. It is not clear to me what to do now. I had implemented this as some fatal error but it is not clear to me what should happen. The V9938 manual says something about setting op the VDP for reading then a prefetch is done by the VDP of the data. But if the VDP address is setup for writing and data is read instead then it can happen that the data is not ready yet to be read, that means that the VDP could not do a prefetch.

 

I suppose that I always store the VDP R/W address and issue a warning in my debug window if the addres is setup for reading but a writa is done instead and visa-versa.

 

 

What Fabrice found with my "use all free CPU time" option was that it was not that my emulator was very very slow, but it was standing still ... no TMS9900 code was executed anymore . I just added some fancy if statements in which the criteria was not always properly set for example when the emulator was started the test was not initialized yet. I have removed the fancy stuff and now it is working again.

 

 

 

Link to comment
Share on other sites

7 hours ago, fabrice montupet said:

On your last version, I have to disable “use all free cpu time” option because if I enable it, that freezes the emulator.

Fabrice, what you found with my "use all free CPU time" option was that it was not that my emulator was very very slow, but it was standing still ... no TMS9900 code was executed anymore . I just added some fancy if statements in which the criteria was not always properly set for example when the emulator was started the test was not initialized yet. I have removed the fancy stuff and now it is working again.

 

I have to clean up the code first a bit  before I give you another unofficial release with maybe some other bugs ?

 

Link to comment
Share on other sites

11 hours ago, F.G. Kaal said:

The >FFFF is written from the ALIENKEY program to the VDP. It is not clear to me what to do now. I had implemented this as some fatal error but it is not clear to me what should happen. The V9938 manual says something about setting op the VDP for reading then a prefetch is done by the VDP of the data. But if the VDP address is setup for writing and data is read instead then it can happen that the data is not ready yet to be read, that means that the VDP could not do a prefetch.

 

I suppose that I always store the VDP R/W address and issue a warning in my debug window if the addres is setup for reading but a writa is done instead and visa-versa.

yeah.. I'm not sure how the 9938 works in that case. The 9918 behaviour is really straight forward - all writes to the address port go to the address register. The >8000 bit makes it also go to the specified VDP register, and the >4000 inhibits prefetch. Since the 9938 has separate registers for read and write (I think?), that does imply that the internal wiring is different ;)

 

Link to comment
Share on other sites

10 hours ago, Tursi said:

yeah.. I'm not sure how the 9938 works in that case. The 9918 behaviour is really straight forward - all writes to the address port go to the address register. The >8000 bit makes it also go to the specified VDP register, and the >4000 inhibits prefetch. Since the 9938 has separate registers for read and write (I think?), that does imply that the internal wiring is different ;)

 

Changed my code a bit. Now a read or write of the VDP is always executed but an error message is given in the debug window that the data read/write data bit (>4000) or register write bit (>8000) is incorrect. I did not recognize a separate register for read and write in the V9938 datasheet though. So I leave this for what it is for the time being.

 

Link to comment
Share on other sites

21 hours ago, fabrice montupet said:

Thank you by advance! I'm impatient to get the new version! but I'm not worried about possible future bugs, your emulator is great. I can't do without it ?

 

And here it is allready Fabrice! the next unofficial release ?

 

Added a feature for halting the emulator when an error occured.

Added a display error message in the debug window.

Disabled "Use all free CPU time" if a CPU delay is set >0

I understand again how that "Use all free CPU time" functions and it is working again.

Updated the TMS9918 and V9938 implementation with the new insights of the passed week(end) and added some error messages if it is all done wrong

 

Now I want to add a feature in the System speed dialog that shows the number of executed instrutions per second.

 

Ti994w62c.zip

 

  • Thanks 2
Link to comment
Share on other sites

Yes!!!  Thank you Fred! ?

All Speed settings work fine, now  we can set the speed depending of the need. And CALL SOUND too, after numerous minutes of tests, I had no issue during a XB256 program is running! That's a real pleasure.

 

That said, I found a strange thing...Here is an example (CPU speed delay 0, "Use all free CPU time" disabled) :

NEW
10 CALL SOUND(100,400,0)
RUN

(note: The duration, frequency and volume are chosen haphazard, The problem is equal with any other value).

 

The program plays the note fine, but when the program ends, and quickly after, the emulator starts to play random notes and noises. Need to reset or produce a Syntax Error to stop the garbage sounds.

Edited by fabrice montupet
Link to comment
Share on other sites

In my previous test , I thought that CALL SOUND worked fine because I was just adding several noise effects in my program, and no frequencies were tested at this time.

Finally, I encounter the problem with frequencies played when CALL SOUND is executed in direct mode or in a XB256 program, it plays the right frequency and duration that I ask but it plays random frequencies or noise just after...

No problem when CALL SOUND plays noise (-1 to -8).

 

 

Edited by fabrice montupet
Link to comment
Share on other sites

Here is the $64,000 question:

Is this a bug in TI994W or is it a bug in XB256?

To find out there must be a simple program that will always cause the problem in TI994W. Then see if it causes the problem in Classic99, Win994a, or best of all, see if the problem exists on a real TI99.

I have been unable to do any testing. I get the error message that it is not a valid win32 application. Will TI99W run on Windows XP? If so, then I need to know how to do that.

 

Link to comment
Share on other sites

16 hours ago, fabrice montupet said:

In my previous test , I thought that CALL SOUND worked fine because I was just adding several noise effects in my program, and no frequencies were tested at this time.

Finally, I encounter the problem with frequencies played when CALL SOUND is executed in direct mode or in a XB256 program, it plays the right frequency and duration that I ask but it plays random frequencies or noise just after...

No problem when CALL SOUND plays noise (-1 to -8).

 

 

I don't see this problem on my side Fabrice, only if I fool arround whith the sound buffer after playing a sound with CALL SOUND or starting the ALIENKEY-X program and pressing F4. The Ti994w is doing nothing by itself with sound ... it is all TI99 code what can generate this.

 

You have the tools to check what is going on with the sound buffer etc using the debugger window and watches.

Enable the SOUND messages and/or check the sound addresses with the watch window.

See also Editor/Assembler manual sound example page 322

Address >83CC pointer to sound buffer in VDP ram

Address >83FD number of sound bytes

Address >83CE sound byte location >01 is VDP

 

After tones are played >83CE is >00

 

afbeelding.png.ecfe86c762a450816e9c6a00215d2cbe.png

Link to comment
Share on other sites

12 hours ago, senior_falcon said:

Here is the $64,000 question:

Is this a bug in TI994W or is it a bug in XB256?

To find out there must be a simple program that will always cause the problem in TI994W. Then see if it causes the problem in Classic99, Win994a, or best of all, see if the problem exists on a real TI99.

I have been unable to do any testing. I get the error message that it is not a valid win32 application. Will TI99W run on Windows XP? If so, then I need to know how to do that.

 

I have changed the VDP code in Ti994w a bit. After reading the TMS9918 and V9938 datasheet I came to the conclusion that it doesn't matter how it is done but there can be a penalty on the real iron.

 

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.

 

The Ti994w is not the problem here imho, it is either the program itself (ALIENKEY) or code the program uses (XB256). I don't know I am not familiair with XB256 yet.

 

I'm using a newer compiler now to build Ti994w because I added speech and Ti994w is still build as a 32bit application but I don't know if it is still running on XP.

I have to make the same changes in the old version of Ti994w that still runs on XP (or my 32bit Windows 10 laptop)

 

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...