new GFX card

페이지 6/20
1 | 2 | 3 | 4 | 5 | | 7 | 8 | 9 | 10 | 11

By Metalion

Paragon (1343)

Metalion의 아바타

12-09-2008, 11:03

Several times on this thread, the failure of the V9990 and the too few specific V9958 software were pointed out as a strong warning towards the development of a new GFX card. I think the point has been made, but IMHO, those failures can be explained by the increased complexity of those VDP as well as the mandatory backward compatibility.

Deep programming and full use of all features of the MSX VDP is not an easy task, we all know that : limited bandwith I/O, VRAM access, complex screen modes ... And each generation of VDP added a new layer of complexity on the previous one, to improve the graphic possibilities, no doubt, but also to guarantee the backward compatibility.

I just read (again) the V9958 manual, and let me tell you one thing : it does not make you want to run and grab your MS2+ to program new softwares ! New bits in old registers, new registers, complex YJK/RGB color storage ... I don't have a V9990 manual (I'm not even sure there's one) but I'm sure it's another ugly mess of bits, registers and mind gymnastics to get a proper result. It's no surprise there was so few softwares developped for those VDP ... Even if the declining MSX market was of course an important factor, at least in the last commercially active years of the MSX standard.

My point is that we could probably need a fancier VDP but first and foremost a simpler one. Direct RAM access, simpler screen modes, easy programming ... Those qualities would surely be assets to insure a better acceptance of the new VDP, as well as more developments. Of course, backward compatibilty is still a must, but if the chosen architecture is the one explained on this thread (video input from the original VDP and video output from the new VDP), then we can have two radically different VDP while retaining the compatibility.

And yes, I also think that it is very important that it stays cheap, in order to be widely spread among our little scene.

By pitpan

Prophet (3135)

pitpan의 아바타

12-09-2008, 14:11

TMS9918 without sprite limitation, pattern-based without 2 colours per line limitation, hardware scroll. That will be it for me. No need for tons of VRAM, zillions of colours or blitting commands. Again, I would be pretty happy with a Sega Master System VDP Wink

By ARTRAG

Enlighted (6493)

ARTRAG의 아바타

12-09-2008, 14:13

that is p1 mode of v9990...

By Trebmint

Champion (294)

Trebmint의 아바타

12-09-2008, 14:17

The other thing that would be vital I believe would be emulator support from the word go. Lets face it most developers are going to develop on PC. In fact developers (we could form a number of groups beforehand) should have several months with the hardware/emulated hardware before the release. Docs should be released before this so tools can be written etc.

Don't just release a piece of hardware, cos if there is no software (and I mean full games - not demos) from day 1 you're always playing catch up, and the doom mongers will be claiming its death, and the developers will be put off further

By Metalion

Paragon (1343)

Metalion의 아바타

12-09-2008, 14:54

TMS9918 without sprite limitation, pattern-based ...
I don't know why some much people are fond of those pattern based screen mode. When I was speaking of complex screen mode, I was refering to these. Seperate pixel and color information ? Come on .... That sucks ! It might be a way to reduce VRAM usage, but it is a pain in the a**.

By Trebmint

Champion (294)

Trebmint의 아바타

12-09-2008, 15:07

TMS9918 without sprite limitation, pattern-based ...
I don't know why some much people are fond of those pattern based screen mode. When I was speaking of complex screen mode, I was refering to these. Seperate pixel and color information ? Come on .... That sucks ! It might be a way to reduce VRAM usage, but it is a pain in the a**.

I agree. Give me a definable 256 palette, byte per pixel, bitmap screen anyday over pattern based screen modes.

By ARTRAG

Enlighted (6493)

ARTRAG의 아바타

12-09-2008, 15:13

Remember that you have a z80 as engine.
patterns reduce the complexity of AI, background manipulation and interaction

The VDP blitter cannot do complex processing, wile the z80 cannot work on pure bitmap due to its speed

You need both, so wile the VDP works on bitmaps the z80 work on patterns and they can work in parallel !!

By MagicBox

Master (198)

MagicBox의 아바타

12-09-2008, 15:14

Patternmode definately has its merits as it allows for quite fast screen updates and 'easy' building of maps. That's the primary reason, not the reduction of VRAM (Screen 4 vs Screen 5). It's much easier to define a bunch of tiles, create a nice looking map with it. However with patterns of 8bpp you have an exponential increase of pattern quality, discarding the need for bitmap mode. Pattern mode --> Speed with a big S

Mind you though, that these patterns are not separate pattern / color definitions like it is in Screen2. There would be no color table in VDPX. A pattern would be defined by 64 bytes. each byte representing one out of 256 colors rather than an on/off or foreground/background pixel

By Trebmint

Champion (294)

Trebmint의 아바타

12-09-2008, 15:56

Well with a decent blitter, or even better a fractional blitter so you can do scaling very easily. Then I'd be happy. Z80 should not have to pump the data about

By DamageX

Master (217)

DamageX의 아바타

13-09-2008, 10:34

Everytime the V9990 is mentioned people say there is no software support for it. Why do you think that producing some other incompatible hardware is going to solve that problem? I mean, talking about imaginary video cards is fun (just wait 'till I get started) but seriously, what's wrong with the V9990? Is the emulation not good enough yet for cross-development?

Anyway, let me tell you what is the ultimate general purpose 2D video controller that never was. It would handle nothing but "sprites" which would just be rectangles of arbitrary size.

The sprites would be bitmapped (bitplanes would work too, if memory size and speed is a tight constraint). The sprites gfx data could also be fetched from a "window" inside a larger bitmap in memory. (in other words, after every scanline the source address increases by more than just the width of the sprite)

Various depths could be supported like 1bpp for text, 4bpp/8bpp/16bpp for graphics. You could also get clever and have a mixed mode where there was 8bpp, but only 128 colors, and if bit 7 was high then it would be combined with the next byte to form a 15-bit RGB pixel that was twice as wide.

The video chip would have some SRAM inside it holding an attributes table for all the objects to be displayed. The list would be processed from start to finish (or at least as far as possible until time ran out) every scanline. The chip would also have two scanline buffers. One buffer would be output to the display (and probably erased/filled with a set value) while the other was re-written with data.

On a low-res (15KHz) monitor, some modest 16-bit bus FPM DRAM from back in the day would have provided enough bandwidth to fill the screen several times over (multiple independently scrolling backgrounds, sprites, score board, etc.). Also, it would be ideal for a graphical multitasking OS. Each application could have its own framebuffer in memory, and the hardware would then easily allow those windows to be resized, stacked, tiled, etc. Any updates to the framebuffers would be displayed immediately without the software having to worry about clipping.

The only part that seems like it would be tricky to implement (I don't really know anything about ASIC design) is the internal logic that allowed writing multiple pixels to the buffer at once. (Since the memory bus would necessarily have to be wider than the color depth to allow a lot of objects on screen, unless the memory clock was higher than the pixel clock)

페이지 6/20
1 | 2 | 3 | 4 | 5 | | 7 | 8 | 9 | 10 | 11