V9958 replacement

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.

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

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.

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.

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.

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.

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.

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.

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.

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).

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.

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.

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

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.

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.

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

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.

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.

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. ;)

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.

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.