Jump to content

Photo

MAME and Geneve emulation issue with Video mode


16 replies to this topic

#1 BeeryMiller OFFLINE  

BeeryMiller

    Chopper Commander

  • 151 posts

Posted Sun Dec 24, 2017 3:48 PM

Michael,

 

I tracked down the issue and I am attaching a diskette image to you.  I can reproduce the error within 6 lines of code, and fix it with another 3 lines of code.  If I had my suspicion, it is a timing issue likely in the 9938 code.

 

Setting graphics mode 7 via the geneve XOP's and immediately setting to Text mode 2 (80 columns) with another XOP, I get a messed up screen.  When I am dumped back to the CLI, I can do a MODE 80 and the screen is restored.   I searched mode 80 code looking for hints, and saw nothing that should have been an issue.

​I then did two back to back Text Mode 2 calls in code with the XOP's, and the problem disappeared.  It looks like the 9938 has not completed processing everything in Graphics Mode 7 and then the call to Text Mode probably interrupts that call.  That is my 2 cents since I am not that familiar with the 9938 code.  However, a second call and everything is then setup properly in the registers.

 

The file TEST-S is my code, and I have a couple of other files from the Geneve VID XOP.  

 

Hope this helps.

 

Beery

 

Attached Files



#2 InsaneMultitasker ONLINE  

InsaneMultitasker

    Stargunner

  • 1,828 posts

Posted Sun Dec 24, 2017 4:09 PM

What happens iwhen you add a delay between the mode 7 and mode 2 calls?  If this is a timing issue, a delay should resolve the problem.

 

I would also question why a program is calling two video modes in succession, as a secondary curiosity.



#3 BeeryMiller OFFLINE  

BeeryMiller

    Chopper Commander

  • Topic Starter
  • 151 posts

Posted Sun Dec 24, 2017 6:45 PM

What happens iwhen you add a delay between the mode 7 and mode 2 calls?  If this is a timing issue, a delay should resolve the problem.

 

I would also question why a program is calling two video modes in succession, as a secondary curiosity.

 

Tim,

 

I ran that test.  Adding a decrementing loop from >FFFF to >0000 between calling graphics mode 7 and then calling text mode 2, it works fine.  There is a timing issue with something with the 9938.  Whether it is with the 9995 talking to the 9938 in emulation or the 9938 too slow or being interrupted with the next call, that is beyond me to know.

 

The code I had was purely an example of calling text mode twice that fixed the issue.  That was not in the stock program, just something I tested to see if it was a timing issue "somewhere".

 

Beery



#4 mizapf OFFLINE  

mizapf

    River Patroller

  • 2,760 posts
  • Location:Germany

Posted Mon Dec 25, 2017 9:02 AM

I measured the required delay as 12ms (4400 loop iterations). I have to look into the code of the v9938.

 

If you want to have a look for yourself: https://github.com/m...video/v9938.cpp

 

Unfortunately, I never contributed anything for this chip, so this is largely terra incognita (apart from the comment "MZ:" and the small fix related to it).



#5 BeeryMiller OFFLINE  

BeeryMiller

    Chopper Commander

  • Topic Starter
  • 151 posts

Posted Mon Dec 25, 2017 9:37 AM

I measured the required delay as 12ms (4400 loop iterations). I have to look into the code of the v9938.

 

If you want to have a look for yourself: https://github.com/m...video/v9938.cpp

 

Unfortunately, I never contributed anything for this chip, so this is largely terra incognita (apart from the comment "MZ:" and the small fix related to it).

 

Michael,

 

I looked at the file.  Other than around line 2001 with notes on parallel processing, I would have no idea where/how timing could be handled.  It is over my head!

 

Beery



#6 mizapf OFFLINE  

mizapf

    River Patroller

  • 2,760 posts
  • Location:Germany

Posted Mon Dec 25, 2017 9:59 AM

OK, I'll check. Maybe it is not so difficult to find as it looks. I notice that the graphics 7 switch takes some perceivable time to complete, which means that the switch is not instantaneous, and so the call must be asynchronous. There is some chance that the new switch breaks the state machine.

#7 mizapf OFFLINE  

mizapf

    River Patroller

  • 2,760 posts
  • Location:Germany

Posted Mon Dec 25, 2017 5:35 PM

Here is a sequence of log outputs that should show us the actual issue. It starts with the execution of the test program.

 

[:vdp] v9938: Write 88 to R#8
[:vdp] v9938: Write a0 to R#1
[:vdp] v9938: mode = GRAPHIC 3
[:vdp] v9938: Write 00 to R#0
[:vdp] v9938: mode = GRAPHIC 1
[:vdp] v9938: Write 0e to R#0
[:vdp] v9938: mode = GRAPHIC 7
[:vdp] v9938: Write a0 to R#1
[:vdp] v9938: Write 80 to R#9
[:vdp] v9938: Write 04 to R#7
[:vdp] v9938: Write a0 to R#1
[:vdp] v9938: Write 1f to R#2
[:vdp] v9938: Write f7 to R#5
[:vdp] v9938: Write 01 to R#11
[:vdp] v9938: Write 1e to R#6
[:vdp] v9938: Write 24 to R#17
[:vdp] v9938: Write 00 to R#36
[:vdp] v9938: Write 00 to R#37
[:vdp] v9938: Write 00 to R#38
[:vdp] v9938: Write 00 to R#39
[:vdp] v9938: Write 00 to R#40
[:vdp] v9938: Write 01 to R#41
[:vdp] v9938: Write d4 to R#42
[:vdp] v9938: Write 00 to R#43
[:vdp] v9938: Write 04 to R#44
[:vdp] v9938: Write 00 to R#45
[:vdp] v9938: Write 80 to R#46
[:vdp] V9938: Opcode 80h  LMMV-SET  (0,0)->(0,0),4 [256,212]
[:vdp] Command started
[:vdp] v9938: Write e0 to R#1
[:vdp] v9938: mode = GRAPHIC 7
[:vdp] v9938: Write e0 to R#1
[:vdp] v9938: Write 88 to R#8
[:vdp] v9938: Write a0 to R#1
[:vdp] v9938: mode = GRAPHIC 7
[:vdp] v9938: Write 00 to R#0
[:vdp] v9938: mode = GRAPHIC 1
[:vdp] v9938: Write 04 to R#0
[:vdp] v9938: mode = GRAPHIC 3
[:vdp] v9938: Write b0 to R#1
[:vdp] v9938: mode = TEXT 2
[:vdp] v9938: Write 00 to R#9
[:vdp] v9938: Write 04 to R#7
[:vdp] v9938: Write b0 to R#1
[:vdp] v9938: Write 03 to R#2
[:vdp] v9938: Write 2f to R#3
[:vdp] v9938: Write 00 to R#10
[:vdp] v9938: Write 02 to R#4
[:vdp] v9938: Write f0 to R#1
[:vdp] v9938: mode = TEXT 2
[:vdp] v9938: Write f0 to R#1
[:vdp] v9938: Write f4 to R#7
[:vdp] LMMV command done

 

[Edit: Changed position of register write logging]


Edited by mizapf, Mon Dec 25, 2017 5:46 PM.


#8 BeeryMiller OFFLINE  

BeeryMiller

    Chopper Commander

  • Topic Starter
  • 151 posts

Posted Mon Dec 25, 2017 6:54 PM

So, if I understand things from the log file you posted, the LMMV-SET is still processing while other register commands are being sent to the 9938 as well, interfering with the LMMV-SET?

 

Will that be a 9938 issue in it's core requiring a fix, or is that doing something a bit different in the TI and/or Geneve emulation with the 9938 access?

​Beery



#9 mizapf OFFLINE  

mizapf

    River Patroller

  • 2,760 posts
  • Location:Germany

Posted Mon Dec 25, 2017 7:09 PM

As it seems, the XOP in MDOS not only switches modes but also executes a v9938 command (LMMV) to clear the screen. This takes some time to complete, and if you switch modes in the meantime, the command will continue to plough through the VRAM.

 

I think I should consult the other devs, particular those who wrote the code. The code states that the commands may only be invoked in the higher graphics modes, so you cannot initiate a command within text mode, but they obviously did not abort the command when the switch is done before the command has completed. The question is: What is the real thing doing? If we consider this program on the Geneve, it may be considered a proof that the command is aborted. To make sure, we should probably write a program that fills the VRAM with some byte, switch modes, and check where the overwrite ends. However, if I remember correctly, the video RAM is organized differently between the modes.

 

At least we can now explain the symptoms: Depending on how early we switch modes, the pattern table in text 2 mode is affected or not. The delay of 12 ms that I mentioned above does not suffice to let the command terminate, but it seems to save the patterns.



#10 InsaneMultitasker ONLINE  

InsaneMultitasker

    Stargunner

  • 1,828 posts

Posted Mon Dec 25, 2017 8:26 PM

I've extracted the routine framework for reference.   It starts with VR#8 (which agrees with your trace) by doing some housekeeping and eventually winds up in a routine to set the mode, reset the character table, and clear the screen.  There are two routines to clear the screen:  one for 'text' mode and one for graphics mode.  The latter uses LMMV, as shown above, to clear the screen with a scroll via GRCLR. (Is a scroll faster than writing to the screen? This routine might need to be looked at). 

 

VDCMD1 and VDCMD2 are the routines that write the registers for the LMMV command.  They both appear to test the status /before/ setting up the registers.  I suspect that if you set video mode to graphics 6 then graphics 7 in succession, the VDCMD1/2 routines would pause for completion of the commands before setting and executing the next.  However, since Text mode scrolling is not managed via VDCMD1/2, there is no command test, and the setup continues during LMMV execution.  It is NOT clear to me why this is a problem for emulation or $$CRASH$$.

 

On a related note it seems strange that MDOS is using a scroll routine to clear the screen during a mode set; there should be better ways to handle this, unless the routines are manipulating the scrollback buffer for the CLI at the same time and/or performing other housekeeping.  I did not investigate this any further.

 

Spoiler


#11 mizapf OFFLINE  

mizapf

    River Patroller

  • 2,760 posts
  • Location:Germany

Posted Tue Dec 26, 2017 4:24 AM

However, since Text mode scrolling is not managed via VDCMD1/2, there is no command test, and the setup continues during LMMV execution.  It is NOT clear to me why this is a problem for emulation or $$CRASH$$.

 

 

Because the command continues to write values into VRAM after the tables have been rearranged?

 

[:vdp] v9938: Write 00 to R#45
[:vdp] v9938: Write 80 to R#46
[:vdp] V9938: Opcode 80h  LMMV-SET  (0,0)->(0,0),4 [256,212]
[:vdp] Command started
[:vdp] addr=000000 <- 04
[:vdp] addr=010000 <- 04
[:vdp] addr=000001 <- 04
[:vdp] addr=010001 <- 04
[:vdp] addr=000002 <- 04
[:vdp] addr=010002 <- 04
...
[:vdp] addr=0004bf <- 04
[:vdp] addr=0104bf <- 04
[:vdp] addr=0004c0 <- 04
[:vdp] addr=0104c0 <- 04
[:vdp] addr=0004c1 <- 04
[:vdp] addr=0104c1 <- 04
[:vdp] addr=0004c2 <- 04
[:vdp] addr=0104c2 <- 04
[:vdp] addr=0004c3 <- 04
[:vdp] addr=0104c3 <- 04
[:vdp] addr=0004c4 <- 04
[:vdp] addr=0104c4 <- 04
[:vdp] addr=0004c5 <- 04
[:vdp] addr=0104c5 <- 04
[:vdp] addr=0004c6 <- 04
[:vdp] addr=0104c6 <- 04
[:vdp] v9938: Write 00 to R#0
[:vdp] v9938: mode = GRAPHIC 1
[:vdp] addr=0004c7 <- 40
[:vdp] addr=0004c7 <- 44
[:vdp] addr=0004c8 <- 40
[:vdp] addr=0004c8 <- 44
[:vdp] addr=0004c9 <- 40
[:vdp] addr=0004c9 <- 44
[:vdp] addr=0004ca <- 40
[:vdp] addr=0004ca <- 44


#12 InsaneMultitasker ONLINE  

InsaneMultitasker

    Stargunner

  • 1,828 posts

Posted Tue Dec 26, 2017 1:43 PM

 

Because the command continues to write values into VRAM after the tables have been rearranged?

 

Agreed, I was musing about the successive use of the mode select XOP.  I understand the reason for the tables being re-arranged but I don't understand why a programmer would call the video mode settings back-to-back. That isn't normal, IMHO.   I wonder if the command is aborted when a mode change occurs, or if the current command executes using the table settings made when the command was triggered?



#13 mizapf OFFLINE  

mizapf

    River Patroller

  • 2,760 posts
  • Location:Germany

Posted Mon Jan 8, 2018 5:21 AM

So I have come to some conclusions now, after days of working with a number of machine language programs that wrote for that purpose.

 

Summary: I patched the v9938.cpp file in MAME to abort a command when the video mode is changed before completion.This is available from Github right now, or on Jan 31 with the next release. This will make the program BEURS usable, at least concerning that reported issue. (Remember to add "-mouse" as a command line argument to capture the mouse.)

 

In detail: I tried to figure out what happens when we switch the mode before the command has completed its execution. For that purpose, I wrote a program that switches to Graphics7, starts drawing a filled box with LMMV, then switches to another mode - a) after waiting for completion, and b) immediately (just by commenting out the JOC instruction). Also, it creates fingerprints of the VRAM by calculating the CRC16 for 1k blocks, once at the start, then again after switching. Later I refined these fingerprints to blocks of 64 bytes.

 

Results:

  1. In Graphics6/7 modes, address line A16 takes the role of the LSB of the VRAM address. (This is well-known, but I could see it directly here.) This means that subsequent pixels of the box drawn at (0,0) change VRAM at locations >00000, >10000, >00001, >10001, >00002, >10002, and so on. This is true for G6 and G7, not for G4 and G5. I wonder whether this is a glitch of the v9938 design.
  2. (already found before) The LMMV command does not immediately stop after the switch. This is obvious by watching the CE bit (command executing); it seems as if the CE bit is 1 just a little bit shorter than in the case where the command is allowed to complete (17000 iterations vs. 19000 iterations).
  3. When the switch occurs, writing to high memory locations (>10000 and higher) stops immediately.
  4. Writing to low memory locations stops at the point when the switch occured, then some isolated bytes are written to VRAM. This means that the BEURS program can cope with the early switch because the pattern tables do not get damaged, or only at isolated locations which may be seen as broken characters. This was not correctly emulated before, where the command continued to write to VRAM, overwriting the Text2 tables.
  5. The locations of the single, isolated bytes that are changed after the switch are not fully predictable. They change for repeated test runs, and they depend on the time of the switch.

From these results, I decided that it should be sufficient to abort the command when the switch occurs. This is certainly not precise in terms of timing behavior and the fact that some few bytes are sputtered over the VRAM, but since that behavior is not fully predictable and reproducible, and I do not know more about the v9938 internals, I cannot emulate it better. I do not believe that any application for a v9938-based system seriously relies on that behavior.



#14 BeeryMiller OFFLINE  

BeeryMiller

    Chopper Commander

  • Topic Starter
  • 151 posts

Posted Mon Jan 8, 2018 6:42 AM

Thanks for the update.  I ran your timing tests on one computer and I got different results greater than your 17,000 and 19,000 iterations.  It was a few days ago, but I got something in the 23,000 range as I recall. 

 

I do not know your system, but I could believe the randomness of the few bytes sputtered over the VRAM could be related to any other tasks running separate of the emulation.  That is just a guess, no evidence one way or the other.

 

For BEURS, I spent yesterday taking the disassembled code and modifying some instructions.  I have bypassed the title screen causing the graphics issue so no matter what version of MESS or MAME someone is using, it will not be a problem.  I have identified the code for the menus and submenus and working through it now to identify the precise piece of code I need to insert to be able to save files.  

 

In all reality, I seriously doubt anyone will use this program when one can no go to Yahoo Financials or their 401K website manager and pull up the data without taking the time to ever type in any data into a spreadsheet.  What I may offer is some graphing opportunities if someone wants to see other data plotted out on the screen.  I have not dug into graphing routines, but it does not appear those routines are causing an issue in the flipping between them and text mode so I believe he is using another mode.

 

Right now, I am waiting on my AT&T guy to come out right now and check my internet line.  As luck would have it, it has been working fine since Friday except for one small timeframe.  I just hope I did not exceed my Verizon Wireless data limit as it is $15/GB.

 

 

Beery



#15 mizapf OFFLINE  

mizapf

    River Patroller

  • 2,760 posts
  • Location:Germany

Posted Mon Jan 8, 2018 6:55 AM


I do not know your system, but I could believe the randomness of the few bytes sputtered over the VRAM could be related to any other tasks running separate of the emulation.  That is just a guess, no evidence one way or the other.

 

 

No, I refer to the real iron. Running on the emulation to be fixed does not make too much sense. ;)



#16 mizapf OFFLINE  

mizapf

    River Patroller

  • 2,760 posts
  • Location:Germany

Posted Mon Jan 8, 2018 8:21 AM

Thanks for the update.  I ran your timing tests on one computer and I got different results greater than your 17,000 and 19,000 iterations.  It was a few days ago, but I got something in the 23,000 range as I recall.

 

Is this the current version? I fixed a speed issue of the 9995 in one release, which became obvious with my Christmas song program that ran far too slowly.

 

If you log the output (add the -log switch), there should be a line

[:maincpu] RESET; automatic wait state creation is disabled

Edited by mizapf, Mon Jan 8, 2018 8:22 AM.


#17 BeeryMiller OFFLINE  

BeeryMiller

    Chopper Commander

  • Topic Starter
  • 151 posts

Posted Mon Jan 8, 2018 10:16 AM

 

 

Is this the current version? I fixed a speed issue of the 9995 in one release, which became obvious with my Christmas song program that ran far too slowly.

 

If you log the output (add the -log switch), there should be a line

[:maincpu] RESET; automatic wait state creation is disabled

 

No, it was not with the current version.  It was MESS that I had on another system.

 

Beery






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users