new GFX card

Page 11/20
4 | 5 | 6 | 7 | 8 | 9 | 10 | | 12 | 13 | 14 | 15 | 16

By MagicBox

Master (198)

MagicBox's picture

14-09-2008, 22:57

That's another way of looking at it and would be supported by this VDPX implementation. I have to say I'm positive I will eventually have a working prototype as I tackled all major design issues for this engine. Now it's time to get down to the metal and code the thing Smile

By Prodatron

Paragon (1797)

Prodatron's picture

15-09-2008, 01:44

Just some little remarks from my side here. This graphic card seems to be a very interesting project. I am (currently) not a game programmer, so I can't speak about the requirements for sprites and the pattern modes. From my side I would be interested in the bitmap mode(s).
The VDP9990 already has very powerful bitmap modes regarding resolution, number of colours and blitter-speed and -possibilities. It's also very easy to work with this chip (easy access, only logical commands etc.).

What I am really missing is a special feature, which would be unbelieveable usefull for SymbOS: Colour-depth conversion on-the-fly for LMMC commands (Logical Move to Memory from CPU).

SymbOS currently supports 4 and 16 colour graphics and has to be able to display these graphics in different screen modes (2 and 4 colours on CPC, 4 and 16 colours on MSX, only 2 colours on PCW Joyce). As an example on MSX I need 4 different routines to display a graphic: 4col gfx in 4col mode, 4col gfx in 16col mode, 16col gfx in 4col mode and 16col gfx in 16col mode. That means, that colour-depth conversion is not only slow, it also requires a lot of additional code, and the available code memory for this is quite limited. Because of this it's currently impossible to add 256colour support. I would have to add 4 additional routines, and the conversion will even be much more slower, as it would be more complex again. An extended LMMC command with the option to convert the colour depth on-the-fly would be a killer feature regarding SymbOS support.

This is only a suggestion. As this graphic card seems to be focused on games, I guess such a feature will have a very low priority. In any case, if it has a nice bitmap mode with 4 or 16 colours and a good blitter, I don't see any problems with supporting it in SymbOS. The GFX9000 driver was so easy and fast to implement (even without an emulator; I wasn't able to run OpenMSX at this time), so I hope it won't be different with your hardware. In this case you would already have several applications running on your card (they don't know anything about the graphic hardware they are running on).

Btw, I would prefer I/O-accessable VRAM like on the old VDP and the G9K much more. Mapping a 16K block into the Z80 address space hides a big part of the normal RAM. Another thing is, that with an LMMC command I don't need to recalculate the VRAM address after each pixel-line on Z80 side. So I don't need to do a "line feed", but just stupid pumping of bytes to the I/O-Port (which is as fast as LDIR).

By MagicBox

Master (198)

MagicBox's picture

15-09-2008, 09:19

I've actually thought that about VRAM paging as well. It does take a chunk out of address space. I don't think it would be too much trouble to support both modes of access, Port and Memory access. As for color conversion, that's rather easy to implement in hardware.

Supporting bitmapped mode is something I have planned, but wouldn't have priority right now. First I want to make the pattern mode and sprite support, then add bitmapped mode(s).

Good feedback there; for the color conversion I would need the desired in/out color formats (bit makeup) you wish supported.

By MagicBox

Master (198)

MagicBox's picture

15-09-2008, 11:29

Just a small update.. As I overlooked something important, it's unfortunately not possible to implement VDPX in the Xilinx device I had in mind. Therefore, I've been looking for alternatives and found it with Altera's Cyclone III FPGAs. They offer a much more powerful model in the desired package format (144 pins FTQP). The cost goes up a little though, this device will cost around $13 per piece. However, the device is very powerful and would allow me to process up to 4 sprites per clock, needing 32 clocks for 128 sprites. I have 60 clocks available per pixel. If the device offers what I sort of expect, I may even have it process 8 sprites in one clocktick. The design is just one extremely big state-machine.

The palette table is going to get a special feature too. A palette entry is 4 bytes. 3 bytes for the color definitiion. The fourth byte is going to be a fade register. No more precalculation of faded values for R/G/B. Just a nice hardware fade per color. There will also be a global fade register. 100% smooth scene fading.. would be cool =)

By Yukio

Paragon (1540)

Yukio's picture

15-09-2008, 13:53

I found a article yesterday about graphic cards.
PCI Express Design Considerations -- RapidChip Platform ASIC vs. FPGA Design Efficiency

I do not know if you like the ASIC vs FPGA discussion ...
Sure, producing a new ASIC should be good enough with the integration of more circuits like sound chips!

Problem is the first design and the quantity of units in the initial order.

By MagicBox

Master (198)

MagicBox's picture

15-09-2008, 13:56

Prototyping / Development cycles you do on an FPGA. Once a design is finished completely and you plan on producing 10,000+ units, then you can hand over your design to have ASICs made for them. ASICs are not an economical solution for any numbers below 10,000 units.

By Yukio

Paragon (1540)

Yukio's picture

15-09-2008, 13:59

Cool!LOL!
This could merge the "two" solutions.

10,000 units is not very high for business or enterprises ...

By MagicBox

Master (198)

MagicBox's picture

15-09-2008, 15:10

But it sure as hell is for my wallet lol

By Prodatron

Paragon (1797)

Prodatron's picture

15-09-2008, 17:52

Thanx for your comment!

for the color conversion I would need the desired in/out color formats (bit makeup) you wish supported.

This is quite simple:

For 4->16 colour conversion:

Source Graphic Byte: AABBCCDD (AA is the left pixel, DD the right pixel)
Destination VRAM Bytes: 00AA00BB, 00CC00DD
...so you add two 0-bits as the high part for each pixel

For 16->4 colour conversion:

Source Graphic Bytes: AAaaBBbb, CCccDDdd
Destination VRAM Byte: aabbccdd
...you cut the two highest bits for each pixel

For 4/16->256 conversion it would be the same like for 4->16 conversion (adding 0-bits), if the bitmap mode is palette based (which is for your card as far as I understood). If not (like on the 9939) you would need a translation table.

Such a conversion feature could have a big advantage for the bitmap mode in general (not only for SymbOS):
You only need to provide ONE bitmap mode (with 256 colours). The applications can still work with FAST 4 and 16 colour graphics, as they are only blowed up on VDPX side, not on CPU side.

By Trebmint

Champion (294)

Trebmint's picture

15-09-2008, 18:18

Prodatron. Have you thought about fixing each version of Symbos to one mode. So you start up in 16 or 4 colour mode, meaning you're not building in routines for modes you're not in. We can get 256 colour mode then

Page 11/20
4 | 5 | 6 | 7 | 8 | 9 | 10 | | 12 | 13 | 14 | 15 | 16