V9958 replacement

ページ 2/4
1 | | 3 | 4

By PingPong

Prophet (3889)

PingPong さんの画像

07-11-2021, 10:51

OCM was developed without knowledge of VDP internal timings (VRAM & command engine timings).

IMHO A real replacement should take into account those details to recreate a hi-fi replacement.

By gdx

Enlighted (5510)

gdx さんの画像

07-11-2021, 11:45

What I would have liked to see in the V9958 is faster commands, additional controls to scroll horizontally or vertically in a defined frame. I would also like to see the color 0 really transparent (to let see the page below and so on until the page of the video input). These two improvements alone would have made it possible to make great arcade-style games very easily with even differential scrolling. MSX2+ was a big letdown to me.

About V9958 replacement, the main goal should be compatibility and size because not every MSX has the same place inside.

By erpirao

Paragon (1261)

erpirao さんの画像

07-11-2021, 12:14

something similar to ize80 or armsid right?

By PingPong

Prophet (3889)

PingPong さんの画像

07-11-2021, 13:33

the improvements you suggest are mostly the same in my wishlist.
However i think that going to far will 'distort' the original spirit of an 8 bit machine. so no fancy 1280x1024 true color res, only a set of small improvements that the v9958 woud have deserved, but with the ability to unlock them

By PingPong

Prophet (3889)

PingPong さんの画像

07-11-2021, 13:35

only in terms of mechanical and pinout compatibility. the ize80 for example serves another purpose.

By sd_snatcher

Prophet (3505)

sd_snatcher さんの画像

07-11-2021, 16:00

IMHO, these were some very important features that went missing on the V9958. It's understandable that some mistakes were made on the rushed V9938 design, but they should have been corrected on the V9958:

(Note1: Some of them were indeed part of the V9978 design.)
(Note2: Others were already mentioned here, so I'm just reinforcing)

  • HMMC/LMMC blitter commands should activate the /WAIT pin. This would make CPU->VRAM transfers much faster, without the need to to check the blitter status bit, while keeping turbo support. This is the sole reason the VDP access was made so slow on the TR.
  • The /CASX pin was a stupid idea. It should have been A8. This would have easily allowed 256KB and 512KB VRAM configurations using 44246 DRAM chips
  • There should be a configuration bit to disable the "special Y coordinates"
  • The unused 4th byte of the SAT entry should select the entry in the sprite color table, just like the 3rd byte selects the pattern
  • Sprite priority: low priority = shows up only on transparent-color areas, like on the NES and SMS
  • There should be a separate palette just for the sprites on 16-color modes (including screen-10).
  • There should be a bit to enable 15bit palettes on any video mode, since the DAC is 15bit
  • Screen-8 should have 15bit palette support
  • It should be possible to read the VRAM pointer value and the VDP registers, specially R#17 and the blitter registers. This would make reentrant interrupt routines much more manageable.
  • Reading the I/O ports 9Ah and 9Bh should read the status registers (R#15)+1 and (R#15)+2, respectively.
  • The blitter should have separate transfer direction bits for both source and destination. This would have allowed nice mirroring tricks.
  • The light-pen interface should never have been removed, as it could also be cleverly used to externally generate vertical screen splits, or any other type of secondary video interrupts as needed.

By PingPong

Prophet (3889)

PingPong さんの画像

07-11-2021, 19:27

Well, there are some improvements that were techically more difficult (in terms of bandwidth) while others are only stupid heritage from the TMS vdp. i list below:

Quote:

HMMC/LMMC blitter commands should activate the /WAIT pin. This would make CPU->VRAM transfers much faster, without the need to to check the blitter status bit, while keeping turbo support. This is the sole reason the VDP access was made so slow on the TR.

Would have been nice, but only for those command? AFAIK you cannot access the command registers when a vdp command is in place.

Quote:

The /CASX pin was a stupid idea. It should have been A8. This would have easily allowed 256KB and 512KB VRAM configurations using 44246 DRAM chips

I think 128K were enough for a 8 bit machine, the msx is one of the 8 bit that have so great amount of vram
To me is not so essential

Quote:

There should be a configuration bit to disable the "special Y coordinates"

Totally agree, was easy to disable at all even without the configuration bit from screen 4 and above . It's a STUPID BY DESIGN (C) TMS FEATURE

Quote:

The unused 4th byte of the SAT entry should select the entry in the sprite color table, just like the 3rd byte selects the pattern

A dream. however here there are bandwidth complications (i think) to fetch an extra byte.

Quote:

Sprite priority: low priority = shows up only on transparent-color areas, like on the NES and SMS

It is not clear to me what you are meaning. can you explain?

Quote:

There should be a separate palette just for the sprites on 16-color modes (including screen-10).
There should be a bit to enable 15bit palettes on any video mode, since the DAC is 15bit
Screen-8 should have 15bit palette support

this could have resulted in additional complexity, for example 256 color palette mean space chip 16 times larger. plus extended from 9 to 15 could have made worse. Good, but IMHO not so essential, we are talking of 8 bit systems.
My list included only things that are stupid and could be changed with minimal effort.

Quote:

It should be possible to read the VRAM pointer value and the VDP registers, specially R#17 and the blitter registers. This would make reentrant interrupt routines much more manageable.

Here the VRAM ptr mechanics is another STUPID THING were the inheritance of TMS causes a lot of problems.
In addition to the non readable registers (and this could apply even to other registers) the VRAM address setup mechanism is convoluted, you split 17 bit address in 8 bit + 6 bit + 3 bit in different areas. the solution would have been like the V9990

But again, having readable registers or alternate vram address ptr setup could be resulted in additional chip space.

Quote:

Reading the I/O ports 9Ah and 9Bh should read the status registers (R#15)+1 and (R#15)+2, respectively.

why this is useful?

Quote:

The blitter should have separate transfer direction bits for both source and destination. This would have allowed nice mirroring tricks.

Useful and doable with relatively small effort.

Quote:

The light-pen interface should never have been removed, as it could also be cleverly used to externally generate vertical screen splits, or any other type of secondary video interrupts as needed.

they did it to free one chip pin. however this made v9958 not fully compatible with v9938...

By sd_snatcher

Prophet (3505)

sd_snatcher さんの画像

07-11-2021, 22:38

PingPong wrote:
Quote:

HMMC/LMMC blitter commands should activate the /WAIT pin. This would make CPU->VRAM transfers much faster, without the need to to check the blitter status bit, while keeping turbo support. This is the sole reason the VDP access was made so slow on the TR.

Would have been nice, but only for those command? AFAIK you cannot access the command registers when a vdp command is in place.

For the other commands, the blitter goes without any need for CPU interaction in the middle. Then the interrupt approach we two commented is enough.

The /WAIT is necessary for the HMMC/LMMC commands because it behaves similar to writing VRAM bytes, where individual bytes can be lost if you write too fast. With the additional problem that the VDP will be locked forever in the command if bytes are lost. This is why most turbo design fail and the machine freeze: some software just wrote to the HMMC command without checking the READY bit.

Quote:
Quote:

The /CASX pin was a stupid idea. It should have been A8. This would have easily allowed 256KB and 512KB VRAM configurations using 44246 DRAM chips

I think 128K were enough for a 8 bit machine, the msx is one of the 8 bit that have so great amount of vram
To me is not so essential

Yes, totally agree with the fact that most of the exaggerated ideas I see everywhere else about how the MSX should have been forget that this was intended to be a cheap hobbyist 8bit computer.

But let's not forget they had ideas for some more powerful professional configurations too, including video editing appliances like the Sony XV-T550 and Pioneer UC-V102. This is why it was important to have kept possible to have turbo CPUs and more VRAM.

They noticed the need for more CPU and implemented the /WAIT for VRAM access. But totally forgot about the LMMC/HMMC commands, which made the turbo CPU almost impossible to do without severely restricting the CPU/VDP access speed as it was done on the Panasonic MSX2+ and the TR machines.

Getting back to the VRAM size, having more pages is very useful on screen-7 and higher, because as you might remember it's not possible to do double-buffering on these modes with only 128KB of VRAM. This is very noticeable on Xak-1.

Quote:
Quote:

There should be a configuration bit to disable the "special Y coordinates"

Totally agree, was easy to disable at all even without the configuration bit from screen 4 and above . It's a STUPID BY DESIGN (C) TMS FEATURE

Curiously enough, AFAIK Yamaha did the exact same blunder on the SMS VDP, and it was only fixed by NEC on the SMS2 VDP.

Again, it was an understandable mistake for the V9938 VDP. But not having fixed it on the V9958 was unforgivable.

Quote:
Quote:

The unused 4th byte of the SAT entry should select the entry in the sprite color table, just like the 3rd byte selects the pattern

A dream. however here there are bandwidth complications (i think) to fetch an extra byte.

AFAIK, the V99x8 always fetch this byte, because the same hw block is used for both mode-1 and mode-2 sprites. It's fetched, but not used for anything. Talk about wasting resources.

Quote:
Quote:

Sprite priority: low priority = shows up only on transparent-color areas, like on the NES and SMS

It is not clear to me what you are meaning. can you explain?

Low-priority sprites pass "behind" the background. This is implemented by using the background transparent color as a mask.

No extra bytes need to be fetched for this, since the raster already has to fetch the background data for each pixel. Then all it needs to do is to check if the background is at a transparent color to decide if it will plot a low-priority-sprite-pixel or a background-pixel. It's cheap and effective.

Quote:
Quote:

There should be a separate palette just for the sprites on 16-color modes (including screen-10).
There should be a bit to enable 15bit palettes on any video mode, since the DAC is 15bit
Screen-8 should have 15bit palette support

this could have resulted in additional complexity, for example 256 color palette mean space chip 16 times larger. plus extended from 9 to 15 could have made worse. Good, but IMHO not so essential, we are talking of 8 bit systems.
My list included only things that are stupid and could be changed with minimal effort.

Yes, of the features I mentioned, this would have been the more expensive to implement. But not impossibly expensive, since the SNES, released only 2 years later, was a cheap machine that had it. And the SNES had with much more complicated ways to subdivide the palette between multiple backgrounds that the V9958 wouldn't need.

But then, at least it should have been made possible to use the palette with the screen-8 sprites. The OR-color sprites are almost useless on screen-8 because of their fixed palette.

This could have been made with minimal effort.

Quote:
Quote:

It should be possible to read the VRAM pointer value and the VDP registers, specially R#17 and the blitter registers. This would make reentrant interrupt routines much more manageable.

Here the VRAM ptr mechanics is another STUPID THING were the inheritance of TMS causes a lot of problems.
In addition to the non readable registers (and this could apply even to other registers) the VRAM address setup mechanism is convoluted, you split 17 bit address in 8 bit + 6 bit + 3 bit in different areas. the solution would have been like the V9990

Yes, getting rid of the legacy TMS way to access the register was necessary at some point and they clearly knew that. Probably the V9978 had both ways to access the VDP (new and legacy) and this was removed from the V9990 amongst all other TI's Intelectual Property (screen0 to 4 and mode1/mode2 sprites).

Quote:

But again, having readable registers or alternate vram address ptr setup could be resulted in additional chip space.

I'm not sure if making all registers readable would have been that expensive. But if that's the case, at least the most important registers needed to restore the VDP state when returning from an interrupt should be readable. This means all registers that the VDP will change the value by itself, like:

  1. VRAM pointer
  2. R#17
  3. All blitter registers

Without (3) the blitter STOP command is not very useful. If the blitter registers could be read an interrupt routine could stop an ongoing blit, make its own blits as necessary, and restore the previous blit after it ended. Or STOP the blitter to be able to change the screen-offset registers and restore the blitter state again afterwards.

Quote:
Quote:

Reading the I/O ports 9Ah and 9Bh should read the status registers (R#15)+1 and (R#15)+2, respectively.

why this is useful?

Because then a lot less multiplexing would be needed when doing either blitting or raster effects. Take a look at the code that do either of these two to see how much the code has to juggle at the single port to read all the needed status registers.

Quote:
Quote:

The light-pen interface should never have been removed, as it could also be cleverly used to externally generate vertical screen splits, or any other type of secondary video interrupts as needed.

they did it to free one chip pin. however this made v9958 not fully compatible with v9938...

But then they splurged on pins making HSYNC/HRESET and CSYNC/VRESET separate unidirectional pins. Yes, that tri-logic nonsense of the V9938 was probably expensive. But it would have been much better to have a bit to configure the pin direction, just like the pin-3 (DLCLK).

IMHO, this is what they should have done with the pins. Much more effective and backwards compatible:

  • pin4: Kept as /VDS
  • pin5: /HSYNC output or /HRESET input. Only modified to have a config bit to select if pin5 & pin6 would be input or output
  • pin6: /CSYNC output or /VRESET input. Only modified to have a config bit to select if pin5 & pin6 would be input or output
  • pin8: CPUCLK or /WAIT: The bit2 of the R#25 would enable the /WAIT, and change this pin function at the same time. Much more useful for turbo machines, since the /WAIT is unnecessary at 3.57MHz, and the 3.57MHz CPUCLOCK is unnecessary when the turbo is enabled.
  • pin21: VDD/DAC. This was necessary because of the new 15bit DAC. Also getting rid of the internal NTSC TV-Encoder for sure freed a lot of chip area. No wonder a whole chip is used for this function everywhere else.
  • pin26: Yay! One free pin to do whatever you want. Could have been /CASX2 (if pin59 was kept as /CASX), or even A9 (if pin59 was changed to A8)
  • pin27: Kept as /LPD

By PingPong

Prophet (3889)

PingPong さんの画像

07-11-2021, 23:39

Quote:

They noticed the need for more CPU and implemented the /WAIT for VRAM access. But totally forgot about the LMMC/HMMC commands, which made the turbo CPU almost impossible to do without severely restricting the CPU/VDP access speed as it was done on the Panasonic MSX2+ and the TR machines.

Umh, i find more limiting the forced wait imposed to r800 or > 3.5Mhz z80 by some "blind" hardware that does not know about VDP working ( to be clear: the MSX ENGINE chips ) than the need to do a poll on a status bit before send a byte expecially if the status bit could be read without too much ceremony (disable int, set the proper status register read value, restore ints and status registers).

About memory size even a 3x faster blitter would not have been able to manage more than 128 k efficiently. It only served as an additional storage or to do triple buffering for example. but again v9958 had worse limits IMHO than VRAM size. Even the theorical 192 VRAM size already on v9938 was not used (maybe because of excessive complications in taking advantage, another mistake)

Quote:

Again, it was an understandable mistake for the V9938 VDP. But not having fixed it on the V9958 was unforgivable.

i can imagine why. I'm almost sure that the V9938 should never been produced.
the msx2 vdp should have been the v9958. but yamaha delayed to much and they were forced to use a incomplete or prototype chip. If you look at vram access timing you have the suspect that some "gaps" in memory access are here to allow the horizontal scrolling via hw. this is a proof they originally planned to have this but never implemented.

So they terminate the chip design with v9958 with enormous delay without fixing some TMS garbage.
Maybe they added some minor improvements but now, i'm almost sure that the v9938 should have not seen the light.
Given that, they made a mistake only once not two times, in V9938 repeating it in V9958.

Quote:

AFAIK, the V99x8 always fetch this byte, because the same hw block is used for both mode-1 and mode-2 sprites. It's fetched, but not used for anything. Talk about wasting resources.

Nope. in sprite mode 2 the color on the SAT is never read, i'm almost sure (check vram timings). Adding that would have used others cycles, unfortunately.

Quote:

But then, at least it should have been made possible to use the palette with the screen-8 sprites. The OR-color sprites are almost useless on screen-8 because of their fixed palette.

yes, this sound misterious to me. Instead of hard coding fixed values they could have used the 16 color sprites managed by palette as was for other video modes. screen 8 with no palette+sprites with 16 color palette.
i Do not know why they made the effort to create a kind of fixed palette for screen 8 sprites while they have already the 16 color palette to use without changing anithing in sprite management. but there should be a reason.

Why you are talking about v9978? there is no proof that existed. time ago i've seen a v9978 datasheet but reading specs it was clearly the v9990 with another model number. no mention of compatibility.
To me the v9978 did not exists.

Quote:

I'm not sure if making all registers readable would have been that expensive.

It is. it increase the number of transistor needed for each bit in register unfortunately.

Quote:

(3) All blitter registers
Without (3) the blitter STOP command is not very useful. If the blitter registers could be read an interrupt routine could stop an ongoing blit, make its own blits as necessary, and restore the previous blit after it ended. Or STOP the blitter to be able to change the screen-offset registers and restore the blitter state again afterwards.

unfortunately, even with readable register there is no way to resume command execution after stopping it. the reason is that the vdp works in a way that make impossible to re-start the command exactly when is was interrupted.

it would have required to change also internal command handling (the state machine behind this) .

By sd_snatcher

Prophet (3505)

sd_snatcher さんの画像

08-11-2021, 00:49

Quote:
Quote:

They noticed the need for more CPU and implemented the /WAIT for VRAM access. But totally forgot about the LMMC/HMMC commands, which made the turbo CPU almost impossible to do without severely restricting the CPU/VDP access speed as it was done on the Panasonic MSX2+ and the TR machines.

Umh, i find more limiting the forced wait imposed to r800 or > 3.5Mhz z80 by some "blind" hardware that does not know about VDP working ( to be clear: the MSX ENGINE chips ) than the need to do a poll on a status bit before send a byte expecially if the status bit could be read without too much ceremony (disable int, set the proper status register read value, restore ints and status registers).

Yes, it's definitely inefficient to do the video /WAIT by some external chip. It has to be generated internally by the VDP. And this is why it was so slow on for the R800.

Had Yamaha implemented the /WAIT for the HMMC/LMMC commands, the R800 access to the VDP could have been *much* faster. And also the turbo on the Panasonic 2+ or the Victor HC-9x.

Quote:

About memory size even a 3x faster blitter would not have been able to manage more than 128 k efficiently. It only served as an additional storage or to do triple buffering for example. but again v9958 had worse limits IMHO than VRAM size. Even the theorical 192 VRAM size already on v9938 was not used (maybe because of excessive complications in taking advantage, another mistake)

At least double-buffering is a must if you don't want to have tearing.

192KB of VRAM is useless because the VDP uses DRAM bank interleaving for screen7 and higher. So it has to be increased in multiples of 128KB: 128, 256, 384, 512 etc.

Quote:
Quote:

AFAIK, the V99x8 always fetch this byte, because the same hw block is used for both mode-1 and mode-2 sprites. It's fetched, but not used for anything. Talk about wasting resources.

Nope. in sprite mode 2 the color on the SAT is never read, i'm almost sure (check vram timings). Adding that would have used others cycles, unfortunately.

You're right. My memory seems to have betrayed me. Smile

Well, this means that we should stop bitching about this limitation. It was the limit of what could be done with the cheap DRAM chips an MSX2 could afford when the V9938 was designed in 1984. Using more bandwidth would have required faster DRAM chips. Changing the blitter engine was what was intended for the V9978 that was delayed. The V9958 was known to be a stopgap because the VDP of the MSX3 was not ready for 1987 as originally planned.

Quote:
Quote:

But then, at least it should have been made possible to use the palette with the screen-8 sprites. The OR-color sprites are almost useless on screen-8 because of their fixed palette.

yes, this sound misterious to me. Instead of hard coding fixed values they could have used the 16 color sprites managed by palette as was for other video modes. screen 8 with no palette+sprites with 16 color palette.
i Do not know why they made the effort to create a kind of fixed palette for screen 8 sprites while they have already the 16 color palette to use without changing anithing in sprite management. but there should be a reason.

It's easy to understand: when the V9938 was designed, having an internal 256 color palette would have been really expensive. So they designed the screen-8 in a way that an external 256-color DAC could be used when needed. This requires fixed colors for the sprites too, since the external DAC doesn't know about the internal DAC palette values.

And it was indeed released as the V99C37. But you can use any standard external video DAC there.

But anyway, they should have placed a config bit to select if the sprites would use the palette or have fixed colors. Since this wasn't done on the V9938, they could have gone for an internal 256-color palette on the V9958, since they had removed a whole big-ass NTSC TV-Encoder and the mouse interface from the chip to free space.

Quote:

Why you are talking about v9978? there is no proof that existed. time ago i've seen a v9978 datasheet but reading specs it was clearly the v9990 with another model number. no mention of compatibility.
To me the v9978 did not exists.

The V9978 never (commercially) existed, just as the MSX3 that was intended to use it. But there are plenty of records that show that both had been planned to be released on 1987 and went into a development hell.

Even the MSX-Magazine mentioned it, and Nishi recently confirmed on Twitter that Yamaha let the V9978 project starve, to focus on the Sega Mega Drive VDP. This resulted on the Yamaha having to do some patchwork on the V9938 with features like YJK that were intended for the MSX3 VDP. This also explains why there are so many design similarities between the Mega Driver VDP and the V9978/V9990.

Anyway, I'm mentioning the V9978 as pure guesswork, not different from your speculation about the V9938 being a prototype and the V9958 being the final product. This is just pub talk with some good beer, between friends. Nothing we ever talk here will change anything that happened. ;)

Quote:
Quote:

I'm not sure if making all registers readable would have been that expensive.

It is. it increase the number of transistor needed for each bit in register unfortunately.

I still wonder how much expensive that would have been. Not sure if it was as expensive as a whole NTSC TV-Encoder they have fit in the V9938. If you ask me which I would prefer, I would peek readable registers in a blink. The damn TV-Encoder wasn't even useful for PAL regions, and had so many artifacts that even NTSC machines avoided to use it.

Quote:

unfortunately, even with readable register there is no way to resume command execution after stopping it. the reason is that the vdp works in a way that make impossible to re-start the command exactly when is was interrupted.

it would have required to change also internal command handling (the state machine behind this) .

Anyway, being able to stop/continue the blitter would have been a bonus.

If at least the (whole, including R#14) VRAM pointer and the R#15 could have been read, it would have made a giant difference.

ページ 2/4
1 | | 3 | 4