What if V9938 never existed?

Master (147)

28-05-2019, 00:31

引用:

Disappointing, mirror is always useful, and for SC7/8 it could helps a lot for saving memory.

引用:

Grauw wrote:
And I do think sourcing tiles from the CPU memory rather than from VRAM page is pretty useful. Especially for ROM based games.

I also think flip/mirroring sprites is alway useful. It doesn't have to have light source when the game occurs in outdoors scenaries. We can see in this video all the sprite poses used by Rygar in Amiga version. There are many duplicated sprite poses. The memory consumption could be reduce almost to the middle.

https://www.youtube.com/watch?v=nkU3nng2bu4

By Grauw

Ascended (10821)

28-05-2019, 01:33

Well, we’ve got what we’ve got.

Sandy makes a nice suggestion which allows mirroring with the VDP, all that follows is complaints . Come on guys, that’s depressing. You’re retro coders! Challenging yourself to overcome the limits is what makes it fun.

Here, I shared this before, but have some overscan, smooth bidirectional scrolling, screensplit overlay windows (animated), 16-colour sprites animated with YMMM, sprite particle effects and palette effects, all on V9958 (walk on the icons to the right). Too bad there’s no screen 11 in there. Or tile animations (yet). Maybe that will get your juices flowing :).

Or maybe a warm cup of copper sky will?

By Piter Punk

Master (232)

28-05-2019, 08:29

PingPong wrote:

Following the what if tendence i post also my question.
Let's imagine that msx2 have used from the beginning a V9958 instead of V9938.
Do you think that this could have been changed the destiny of MSX in a sensible way ?
I mean for example the availability of games or interest in msx before users moved to other system?

I don't believe it will have any difference at al. A greater achievement would be if the MSX1 was born with the V9938. Following this way we would have 80 columns and bitmapped modes without color-clash from start.

A lot of "deffects" of V9938 weren't deffects, it was designed this way. As far we have documentation, there were some requisites for the new MSX chip:

Microsoft asked for an 80-columns text mode and the blink table;
NTT asked for CAPTAIN support, probably the light-pen support was also their idea;
Victor asked for superimposer and NAPLPS support;
Nishi itself asked for photo-realistic mode and probably the digitizer support;

It's not a requisite, but is noted in Yamaha developers interview that:

Game related enhancements weren't the ASCII's focus in V9938 development.

So, it's a VDP that cover all the requisites desired by their creators. Sadly nor Nintendo or Sega was part of MSX consortium. So, nobody was there to defend the need of better game related functions.

By PingPong

Enlighted (4155)

28-05-2019, 09:12

引用:

I also think flip/mirroring sprites is alway useful. It doesn't have to have light source when the game occurs in outdoors scenaries.

A not so important scenario. Following your path, one could also complain the lack of support for a shadow, a variable zoom of sprites etc. (x1, x2,x3) but i think those features are a lot less important when compared with what are design mistakes that already we already mentioned.
We must also take in consideration that even C64 sprite system supported flipping, and c64 developers lived happy even without this.

By RetroTechie

Paragon (1563)

28-05-2019, 09:23

Piter Punk wrote:

That's a biggie right there. 80 columns doesn't require much in the way of bandwidth, only a higher pixel clock. That alone would have made a big difference for running business, CP/M ported software etc.

I don't understand all this 'bashing' of the V9938 shortcomings in this thread. Sure the V9958 had a few very useful improvements (although imho it's basically a V9938 with some cosmetic upgrades). But the V9938 was a very advanced VDP for its day. Just look at competitors at the time like ZX Spectrum, C64, Amstrad CPC - pathetic in comparison. Commodore Amiga & co were still far on the horizon.

引用:

So, nobody was there to defend the need of better game related functions.

That's stupid in any case. Introduce a new home computer in the '80s, first use: games. Intended or not. Either design a new machine for that, or be stupid. If new machine does games well, it can also do business software, GUI's, etc.

By DarkSchneider

Paragon (1030)

28-05-2019, 09:51

Grauw wrote:

You can send data to the HMMC VDP command at pretty much full throttle, no need to poll the TR flag which slows it down by a lot. All real turbo hardware has automatic waits inserted on VDP access (exactly what you wish for), and FPGA emulations don’t have access speed restrictions.

That the waits are not fed by the VDP but through another mechanism (V9958’s /WAIT may seem ideal on paper but there must be a reason they didn’t use it) doesn’t change the fact that you can assume them to be present and rely on it to prevent you from accessing the VDP too fast on a turbo CPU.

Alternatively, you could poll TR if you detect a turbo CPU, and skip it if it’s a regular 3.58 MHz Z80.

(p.s. The OCM / Zemmix Neo turbo mode completely messes up the cartridge bus timing, very nonstandard, causing signal level incompatibilities with a lot of hardware especially > 8 MHz. Would be nice if that was fixed, similar to the turboR.)

The truth is that developers need standards, not conditional. The ideal would be to use the BIOS functions, so each system use what it has incorporated. Being the best one that with the real WAIT (not the half-implemented so not used one).
Also what about the case you are using blitter and at the same time want to copy data from CPU?

Sadly the reality is that there was many good ideas but many of them not fulfilled.

I don't see the problem on the VDP itself, but on many other things around on the system, "easily" fixable probably by taking some more time to finish them, beign more strict with manufacturers (the 2+ case is really terrible) like IBM was (all manufacturers had to meet the standard specifications), and some others considerations that maybe they didn't give importance like using the Z80 interruption vector jump table that could help a lot for system handling (they could have fixed it on MSX2 even if on MSX1 they didn't care, a big failure).

By tvalenca

Paladin (747)

28-05-2019, 15:55

PingPong wrote:

this does not surprise me at all. it is well known that ppu is basically a copy of tms

right?

By snake

Expert (71)

01-06-2019, 22:40

Msx2 with Fmpac performs more or less like Msx2+; 9958 was a nice upgrade but nothing revolutionary. It wouldn't have changed history. BTW, Msx 2 and 2+ were very good machines. I got really impressed the first time i played a Msx 2 game (Usas) and the first time i plugged Fmpac (Fray) back in early nineties.

Mistakes were Msx 1 and Turbo-R. Both machines were underpowered. Turbo-R is a total mess, even audio circuit is buggy!