Menu

#306 Mirrored VDP mode doesn't work on Toshiba VDP's

open
nobody
Graphics (138)
5
2014-11-22
2009-01-31
No

<n_n> mirrored mode however is known not to work on toshiba vdp
<n_n> to clarify
<n_n> mirrored mode = screen2 with a mask on the pattern or color table address to make it use less than 3 separate tables

<Quibus> mirrored mode doesn't have a test in ident.bas, right?
<n_n> it does
<n_n> it's the 'do you see this text 3 times?' test
<Quibus> ah
<Quibus> mirrorred mode works always, except on Toshiba MSX1 VDP's?
<n_n> yes, it works on v9938/58 too

So, also testable with ident.bas. openMSX doesn't emulate this difference at all.

Discussion

<< < 1 2 (Page 2 of 2)
  • SD Snatcher

    SD Snatcher - 2014-07-22

    And here is the spreadsheet used for the calculations, with the new method-4.

    It also includes the Toshiba palette properly scaled to 8bit/channel with the rule of three, instead of simple bit-shifts.

    Edit: Updated the spreadsheet to fix the incorrect color-9 value.

     

    Last edit: SD Snatcher 2014-07-22
  • SD Snatcher

    SD Snatcher - 2014-07-22

    I need to know whether I should consider them PAL or NTSC to know whether the emulation should use PAL or NTSC timing.

    I almost missed this question.

    The NTSC/PAL pin of the Toshiba VDPs behave exactly as the bit1 of R#9 on the V99x8 VDPs. But as they had no extra register to fit this bit, they just provided it as an external pin.

    This means that just like the V9938/58, the Toshiba VDPs shouldn't be considered PAL or NTSC specific.

     
  • SD Snatcher

    SD Snatcher - 2014-07-22

    I just edited the previous posts to fix an error in the spreadsheet that resulted in an incorrect Red value for the color-9.

     
  • Manuel Bilderbeek

    FYI (and thanks to hap) I'm attaching the palette as he captured it for his T6950 MSX (Sony HB-10P).

     
  • Manuel Bilderbeek

    FRS, thanks a lot for this idea of assuming a DA converter. We (hap and I) think it's better than my method 3, so I changed the code and got this result. (Now without scanlines.)

     
  • Manuel Bilderbeek

    Also, about the NTSC/PAL, I think I wasn't clear. What I meant is: I need to somehow model how it is hardwired, so I made a PAL and an NTSC variant, with the only difference the timing.

     
  • SD Snatcher

    SD Snatcher - 2014-07-22

    Interesting! Is this a capture from composite video or RGB? The rest of the colors seem to be the same, but the reds are very different from the ones on the T7937A. If it's from RGB, then the T6950 colors will also have to be captured with a digital oscilloscope.

    Thinking a bit more about the issue, it can also be caused by a bad tweaking of the video signal by some engineer that believed that the white color was indeed the max level. This could cause the other colors to be distorted as shown.

     

    Last edit: SD Snatcher 2014-07-22
  • Manuel Bilderbeek

    This capture is from RF, if I understood hap correctly.

     
  • SD Snatcher

    SD Snatcher - 2014-07-24

    After consulting the T6950 pinout I recalled an unfortunate fact that I had forgotten. This chip only has a composite-video output, just like the TMS9118.

    So it will not be possible to capture its palette using an oscilloscope.

    I asked Werner to do some testing with his machines, to try to decompose the problem.

    1) Capture the composite-video of both the T7937A and T6950 in a machine different from the HB-10P.

    2) Capture the composite-video of the T6950 from his MB-H50

    3) Capture the composite-video of the T7937A from his HX-91.

    I'm working with the following scenarios:

    a) Both T6950 and T7937A have the same palette, but something is causing distortion. Either a bug in the composite-video encoder (can even be PAL only), or some mistake done by Sony on the HB-10P/20P

    b) The T6950 has a different palette from the T7937A. Then the only resource we would have would be to sample its composite-output (not RF) on a PC capture card using horizontal color bars, in both NTSC and PAL modes. Then try to find the original palette by calculating the color distortions caused by the NTSC and PAL color systems.

     
  • SD Snatcher

    SD Snatcher - 2014-07-27

    are the colors of NTSC(TMS99X8A) and PAL(TMS9929A) the same? If not, is it known what the differences are?

    I saw a lot of complaints (not openMSX specific) about incorrect colors rendering of the TMS9928 emulators, and given your question and the fresh knowledge from the T7937A palette reverse engineering, I decided to dig further into the TMS palette too.

    Richard F. Drushel's article in particular got me intrigued. I decided to do my own color checks on my Gradiente Expert 1.1 and a recently acquired Sharp Hotbit 1.2, as I recalled that back in the days they had different tones but the very same VDP. But since memory of so long ago could be tricking me, I decided to run a re-check.

    And the tests confirmed. The palette of the Expert is clearly different from the one shown in the Hotbit. The Hotbit shows a palette that is very similar to the one in the Drushel's article, with orangeish reds. OTOH, the Expert palette reds looked brownish like the Wikipedia one that openMSX currently uses.

    That certainly was a call for some research. What should be the real TMS9928 palette anyway? People usually guessed that the TMS9929 had a different palette from the TMS99x8 brothers, but here I had two machines with the very same VDP and different color outputs.

    In the end, the answer was simple. The fact is that the TMS9x2x VDPs output their colors in component-video instead of RGB, so a TV-encoder must be used to do the proper conversions. These days TVs have component-video inputs and do their own conversion to RGB internally. It's now possible to connect a TMS9x2x VDP to the TV, by just adding a line driver chip in the middle. (intermediary conversion isn't needed anymore)

    Of the original hardware, the only chips that had the Texas own color encoder built-in were the TMS9x18 duet. So, I decided that their color palette should be used as the reference to check the proper color tones. Also considering some NTSC hue distortion, of course.

    I then decided to apply the method-4 against the TMS9928 voltages shown in the datasheet, and it was very exciting to discover that the TMS9928 has a 5bit/channel DAC. For the very first time the real YPrPb palette was available in digital form.

    With that precious info at hand, I looked for the official way to convert the colors. The standard for doing this is the ITU-R BT.601

    Guess what happened after I applied the official formulas over the TMS YPrPb palette? Yes, there it was. The tones closely resembled the ones from the Drushel's article and the Hotbit!

    But I guess that a lot of people in PAL areas won't recognize the orangeish tones TMS9x18 as their fond memory of MSX gaming, as they seem more used to the reddish tones like the Expert had. I had to dig more about the color encoder chips to have a better answer.

    Researching a bit more, I found there were different algorithms for color conversion, and that is what was causing the color differences:

    1) ITU-R BT.601: This is the standard for SDTV and the official one. It was used in the following TV-encoders: TMS9918 built-in, LM1889.

    2) El Cheapo RGB Analog Converter: This is the typical cheap discrete transistor+resistor based analog conversion done in the 80's, and it has some shortcuts in order to save components and costs. It results in more reddish red colors that most European users will probably recognize. It's featured in the vast majority of MSX1 models that have a TMS992x with SCART/RGB outputs. Also used when the machine has the MC1377 TV-Encoder. The T7937A palette seems clearly inspired by this formula.

    3) Analog with per-channel normalization: This is an enhanced version of the El Cheapo. It features trimpots or some other way that allows each channel output to be adjusted independently, as a form of rudimentary white balance. It results in more reddish tones for the red colors. The MSX2 palette seems to be clearly inspired by this formula, with over saturation and some extra manual tweaking.

    4) Analog YPbPr->RGB: This is what you get it you connect the TMS992x directly to a modern TV, with just a line driver chip in the middle. Curiously enough, if you flood the saturation knob to 100% you will get the Konami Game Collection colors. Now we know how Konami arrived at that palette.

    So, the final answer is that proper emulation of the TMS9928 family colors should not only emulate the VDP, but the TV-encoder chip used in each machine.

    I attached a spreadsheet with the palettes and conversions.

     

    Last edit: SD Snatcher 2014-12-07
  • SD Snatcher

    SD Snatcher - 2014-11-20

    We discovered that there's a fifth type of color conversion: The Fujitsu FM-X features a 3bit digital palette on its RGB output.

    I attached a picture taken by Werner, of the Fujitsu FM-X running my new Colorbar program, where the colors are ordered so you can better compare the shades of the same tone, or some tones with the closer ones. It also features larger boxes than the older colorbar test, so we can more area without the dot crawling effect on composite video output.

    I slightly modified it after Werner's shot to show black numbers for the gray color, because the white numbers were "invisible" on that background in this machine.

    Note: The RF output of this machine probably features the BT.601 palette though.

     

    Last edit: SD Snatcher 2014-11-21
  • SD Snatcher

    SD Snatcher - 2014-11-21

    I wouldn't know if it's going to be emulated or not, as I'm just an user who likes to gather/contribute rare docs and hard-to-find info for the openMSX team. It's up you (the team) to decide whether something is interesting to emulate or not. :)

    My humble 2 cents this matter is that machines with unique features are those that are worthy to be emulated exactly because of such differences. Otherwise openMSX would end up being able to emulate thousands of nearly identical MSX machines that wouldn't make any difference to the end user or MSX programmer.

    Note: I didn't mean the above commentary to be offensive in any way. It's just my point of view and nobody is required to agree with it.

     
  • Manuel Bilderbeek

    It's good to have the info documented, if only here it's already better than nothing :)

    I am just trying to explain what you could expect from the (current) openMSX developer team. I love emulating perculiarities, but some are so extreme (and quite some work) that it's hardly worth it. In my personal opinion (and I don't expect anyone on the current team to disagree). But as always: you never know :)

     
<< < 1 2 (Page 2 of 2)