POLL: AVDP from texas

페이지 3/4
1 | 2 | | 4

By hit9918

Prophet (2895)

hit9918의 아바타

05-09-2019, 20:20

Quote:

Look at the stupid magic Y coordinate. It's an invention of Yamaha or an invention of TMS?

this stupid Y coordinate gets a problem when it rolls into visible area, and this was made by yamaha.

By PingPong

Prophet (3529)

PingPong의 아바타

05-09-2019, 21:41

hit9918 wrote:
Quote:

Look at the stupid magic Y coordinate. It's an invention of Yamaha or an invention of TMS?

this stupid Y coordinate gets a problem when it rolls into visible area, and this was made by yamaha.

the stupid problem gets a problem because it shitty by design. And shitty designs are more evident when there is some evolution. like on V9938. If the TMS never had this, no problems in such evolution. Or if TMS had a more proper solution (a bit to enable sprite visualization like VIC-II) no problems in evolution.
And of course it's not a problem on TMS. It does not have even a vertical scroll register a thing that more simpler VDC have (like motorola 6845)!

By PingPong

Prophet (3529)

PingPong의 아바타

05-09-2019, 21:50

hit9918 wrote:
Quote:

Simple: the 9938 is what it is mainly because of the TMS9918. For example: look at the stupid sprite color by scanline

all this is BUSTED by the sega. as a living proof of how it can be done without the quirk.

Exactly. this Prove my theory. The only way to make things better it's to throw in the bin all the TMS VDP crappyness.

But they needed two sprite engines. a lot of space wasted that maybe prevented some good V9938 features.

the problem is not that TMS is a limited chip. A lot of chips have drawbacks and limits.
the problem is that TMS is one example on how a chip can be designed in a such crappy way.
a lot of resources wasted in a horrible implementation.

And the living example on how yamaha got things right is the V9990. Good design, but at a cost, no crappy TMS heritage.

and honestly i cannot agree on the first post here: https://atariage.com/forums/topic/80130-tms9918-rant/ by bruce tomlin.

Quote:

I've been tinkering around with doing some CV code lately, and it's really amazing how the TMS9918 managed to miss getting things right.
The main problem is one word: COLOR

By Grauw

Ascended (9170)

Grauw의 아바타

05-09-2019, 22:08

PingPong wrote:

and honestly i cannot agree on the first post here: https://atariage.com/forums/topic/80130-tms9918-rant/ by bruce tomlin.

That’s quite an unfair comparison he’s making, the TMS9918 was introduced in 1979 and (one of) the first in its class. The NES was released in 1985, the same year as the V9938 which has a much broader palette than the NES and true high res full colour bitmap modes. That would be a more fair comparison, though equally pointless since you will find they have a very different focus.

By PingPong

Prophet (3529)

PingPong의 아바타

05-09-2019, 22:21

Sorry, i've omitted some text:

Quote:

and honestly i cannot agree on the first post here: https://atariage.com/forums/topic/80130-tms9918-rant/ by bruce tomlin.

should be:
and honestly i cannot agree on the first post here: https://atariage.com/forums/topic/80130-tms9918-rant/ by bruce tomlin.
but one thing is clear: there are a lot of stupid design mistakes in TMS, and i find simply ridiculus to BLAME the V9938 for mistakes that are here only for the main reason: maintain compatibility with a crappy design.
If _Yamaha designers had free hands in designing sprite engine i'm sure that some horrid mistakes would not have been done

By Grauw

Ascended (9170)

Grauw의 아바타

05-09-2019, 22:31

PingPong wrote:

and i find simply ridiculus to BLAME the V9938 for mistakes that are here only for the main reason: maintain compatibility with a crappy design.
If _Yamaha designers had free hands in designing sprite engine i'm sure that some horrid mistakes would not have been done

That I can certainly agree with.

Although I think any chip which needs to be backwards compatible with another which was designed in a completely different era (when sprites were a brand new concept, RAM was much more expensive than only a few years later, and nobody had ever heard of a palette yet), will be hampered by legacy design. I certainly can’t blame Yamaha but given the constraints of the time I can’t really blame TI either. Was there any better VDP in 1979?

By PingPong

Prophet (3529)

PingPong의 아바타

05-09-2019, 23:10

Grauw wrote:

Although I think any chip which needs to be backwards compatible with another which was designed in a completely different era (when sprites were a brand new concept, RAM was much more expensive than only a few years later, and nobody had ever heard of a palette yet), will be hampered by legacy design. I certainly can’t blame Yamaha but given the constraints of the time I can’t really blame TI either. Was there any better VDP in 1979?

Well, this is not a problem of tech limits. Of course limits are there. but one can do things in a way to alleviate limits. not to make them heavier or to create new ones.What i mean is: "OK, you do not have bandwidth for a full bitmap mode @ 16 color?" i will live with that. See how can trade resolution for colors. maybe we can get a 128x192 @16 color with the same amount of vram & bandwith? if yes, try to get it. Is this possible? Let's see. we can fetch two bytes+1 byte of name table for every 8 screen pixels, how we can "use" them? well we can do 4 fat pixels @ 16 color or 8 normal pixels @4colors....
Instead what we got from TMS 9918? A pratically unuseful screen 3 with a resolution more like a text mode than a graphic mode.

Look at the choice of the I/O protocol to set VRAM address. It's simply unwise to encode the write mode/read bit and the mode bit in the same byte that represent the 6 most significant digits of the vram ptr. Why? because have disadvantages:

- slow down the process of setting the vram ptr by the requirement of setting the proper bit and masking the address part instead of directly pushing the high byte. ***
- if at any time i release a successor with 32KB of vram, voilà: i'm stuck: have to split the additional address bit somewhere. the way the vdp implement this protocol is naive

let's see one hypothetical alternative :
(set vram ptr for write)

ld a, l
out (0x99),l
ld a, h
out (0x9A),h
ld a, data
out (0x98),a

(set for read)
ld a, l
out (0x99),l
ld a, h
out (0x9B),h
ld a, data
out (0x98),a

(only alter the high byte)
out (0x9a),a

It's only an example.

*** please note that the way it works is not inherent to the VDP design. one could have implemented things like in the example. Nevertheless, even TI/99 works in this crappy way. on msx they simply copied the same design.

these are only examples...

By thegeps

Champion (485)

thegeps의 아바타

06-09-2019, 09:40

With 'if' and 'but' we can change the history... MSX2 designers could have implement a totally new VDP in the same motherboard with 9918 (for compatibility) and use 9918 superimpose feature to use both processors at the same time...

By PingPong

Prophet (3529)

PingPong의 아바타

06-09-2019, 11:30

thegeps wrote:

With 'if' and 'but' we can change the history... MSX2 designers could have implement a totally new VDP in the same motherboard with 9918 (for compatibility) and use 9918 superimpose feature to use both processors at the same time...

and the costs?

By thegeps

Champion (485)

thegeps의 아바타

06-09-2019, 13:02

Are you Karl Guttag? LoL! Why talking about costs? Here we are talking about a never released VDP, and nonsense whatif... Do you prefere if I say "Yamaha engineers could have maintain full compatibility with 9918 for existing screen modes and implement new modes totally free from 9918 heritage". I mean no magic number: you know, 208 for 9918, 212 for 9938 so magic number for 9938 Is not for 9918 compatibility. So they could have...

페이지 3/4
1 | 2 | | 4