V9978... what could it have been?

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

By Manuel

Ascended (19470)

Manuel さんの画像

18-05-2019, 17:34

So, we know about the plans for V9978, but we got V9990 instead. What would V9978 have been?

I mean: suppose you would make a chip that is a V9990, but would be backwards compatible with the V9958. What would it look like? So, VRAM layout, register mapping, etc.

It could be nice to create such a thing in FPGA or whatnot (the MSXVR actually inspired me for this post)... as if it would have been actually created. But for that, it would be nice to speculate what would have been the most probable design.

So it should be:
1. fully V9958 compatible (otherwise it's not an upgrade for an MSX3)
2. be very much like V9990 as well (as that is what was concretely created.... derived from the thing we're trying to extrapolate here). So, where not conflicting with requirement 1, it is like V9990.

What do you think?

ログイン/登録して投稿

By Sepulep

Resident (36)

Sepulep さんの画像

18-05-2019, 17:47

I have wondered why there is no high color and or high resolution pattern modes in the 9938, would this be useful?

By Manuel

Ascended (19470)

Manuel さんの画像

18-05-2019, 18:01

My intention is not to invent new modes... more to see what is logical deduced V9978 given the two requirements above.

By PingPong

Enlighted (4142)

PingPong さんの画像

18-05-2019, 18:41

Manuel wrote:

So it should be:
1. fully V9958 compatible (otherwise it's not an upgrade for an MSX3)
2. be very much like V9990 as well (as that is what was concretely created.... derived from the thing we're trying to extrapolate here). So, where not conflicting with requirement 1, it is like V9990.

What do you think?

Umh, this retro-compatibility is "a too big effort", manuel. If you think a bit it was already happened.
look at v9938. the requirement of compatibility forced designers to make non optimal solutions. with the huge bandwidth available on v9938 the performances could have been a lot better.
Look at the choices done in the sprite system. The main reason of having a SCT was the compatibility with TMS that have monochromatic sprites.
The SMS changed a lot in the new sprite system and this resulted in a better sprite system. But of course a lot of things changed, for example the way the SMS VDP fetch and interprets sprite data (look at the sprite layout in SMS SPT)

And take into consideration that in the case of v9978 this could be worst. you have a new chip like V9990 that is required to maintain compatibility not only with TMS but with two chips, the TMS and the V9958/38. A lot of garbage means a lot of compromises.
IMHO this chip never existed because of the difficulties of reconcile a V99x8 chip already full of quirks and compromises (due to heritage of TMS) with a new clear architecture like the V9990.

for example look at the protocol needed to set the VRAM PTR on V99x8 and on V9990.
Not only the V9990 one is better engineered, but is more clear, logic and powerful. the v99x8 is a crappy one that exists as is because of the TMS compatiility. the choice to encode in the second byte you send to VDP two bits that semantically are not addresses but more a selection of mode of work of the VDP was a real disaster and precluded a more intelligent use of the byte only for address setup purpose.
They maintained this crappy thing because of compatibility and this result a big overhead for the CPU needing to split a register in bits, sending some to one register and other to another. (My GOD)

The V9938 sprite system introduced the OR color trick because of inability to have a proper colored sprite, but the V9938 had a potential of doing a good sprite system like SMS. It happened in this way because of compatibility

I suspect that even if yamaha succeeded in V9978, the tricks they would have forced to use also could have some negative impact on the V9990 parts in terms of limitations.

To be is more logical to think the V9958 as a two system on a chip, maybe internally superimposed or switchable when required. Essentially two cores:
Do you need compatibility? switch on the v9958 core by setting a register. The V9990 is disabled and the output is for v9958 core in the V9978 chip.
Do you need a proper VDP ? switch on the V9990 and shutdown the V99x8 in the V9978....

I do not see a better solution. full compatibility in a single chip is a goal to much ambitious given the existing situation.

By PingPong

Enlighted (4142)

PingPong さんの画像

18-05-2019, 18:37

Sepulep wrote:

I have wondered why there is no high color and or high resolution pattern modes in the 9938, would this be useful?

a screen 5 pattern mode would be good with h scroll register. unfortunately when you look at memory bandwidth......
this is probably the reason of screen 4 mode.

By Sepulep

Resident (36)

Sepulep さんの画像

18-05-2019, 21:55

what is/was the limitation?? - with a 21Mhz clock it doesn't seem impossible...

By PingPong

Enlighted (4142)

PingPong さんの画像

18-05-2019, 22:11

In general, the problem with V9938 is that has a lot of memory access slots during a scanline, but it is also requiring a lot of cycles to perform operations and some time it waste a lot of them.
A stupid example: the c64 sprite system fetch the exact number of bytes it needs to draw on a scanline.
So you had two sprites? two x 3bytes fetch operations = 6 bytes fetch
VDP always does 8 x 2bytes=16 bytes fetch operations even without sprites to be displayed.

If you want to have an idea on how vdp works, see this:http://map.grauw.nl/articles/vdp-vram-timing/vdp-timing.html
plus you need to allow memory slots even for the inefficient blitter that requires some time.

By DanySoft

Champion (452)

DanySoft さんの画像

18-05-2019, 22:50

PingPong wrote:
Sepulep wrote:

I have wondered why there is no high color and or high resolution pattern modes in the 9938, would this be useful?

a screen 5 pattern mode would be good with h scroll register. unfortunately when you look at memory bandwidth......
this is probably the reason of screen 4 mode.

Screen 4 ?

I would like to have the table names as in screen2/4 for screen 5 !!!
Sometimes I don't understand with screen4 because it was similar to screen 2 but with palette + multicolor sprites ?

Bye bye
DanySoft

By gdx

Enlighted (6223)

gdx さんの画像

19-05-2019, 14:05

I have never looked at the V9990 specifications before.

I think it is not a problem to make a VDP with dual core (V9958 and V9990 switchable). The main problem was just the price (dual core + decoders of video input/output for TV and monitor).

And now, looking at the specifications, I note that the V9990 uses 16 I/O ports. Used ports are 60h~6Fh. The first problem is they conflict with the ports 64h and 65h of Panasonic MSX2+ with the turbo mode. The second is that you have to find a place for the system to store their values. Also, the v9990 involves a new way of handling Kanji/Hangul.

By PingPong

Enlighted (4142)

PingPong さんの画像

19-05-2019, 16:33

Quote:

The first problem is they conflict with the ports 64h and 65h of Panasonic MSX2+ with the turbo mode.

Interesting, what do you expect will happen if one try to use V9990 with panasonic MSX2+ ?
Aren't those ports the so-called swithed ports ( which are dependant on the manufacturer) so no conflict?

By PingPong

Enlighted (4142)

PingPong さんの画像

19-05-2019, 16:37

gdx wrote:

I have never looked at the V9990 specifications before.

I think it is not a problem to make a VDP with dual core (V9958 and V9990 switchable). The main problem was just the price (dual core + decoders of video input/output for TV and monitor).

I expect the price not so high, the design costs were already payed, it's a matter of production costs.
for the video input / output i think could be the shared part between the two cores, but i'm not able to say if it is techically doable..... another option is a kind of superimpose, but this means to have both vdp enabled, so the twice bus, control lines, hw signals and memory interface ..... that in the switchable option could have been shared.

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