FPGA VDP Enhanced?

Page 2/3
1 | | 3

Par frederic.markus

Expert (82)

Portrait de frederic.markus

18-09-2019, 11:20


* 640×480@60 analog VGA output to drive a standard computer monitor. This was the main reason for the F18A’s existence at all. 640×480 was chosen because it is supported by every VGA monitor since about 1987. Also, to support the original 256×192 pixel resolution I needed to double each VGA pixel to make one “fat pixel”, and 256*2=512 with a 64-VGA-pixel border on each side (640-512=128/2=64). 800×600 was also considered with 3×3 “fat pixels”, but… I can’t remember now, but I spent a lot of time on which VGA resolution to use and 640×480 won.

* A binary compatible TMS9900-based GPU. This is a full-blown CPU inside the F18A, which basically gives you a 100MHz 9900 as a co-processor with direct access to the VRAM, VDP registers, and a private 2K of RAM above the original 16K of VRAM. The GPU performs a complete fetch, decode, execute, store cycle in about 150ns (nano seconds) average, but it depends on the addressing modes of the instruction, and the instruction itself (jump and branch instructions only take around 60ns). This give a performance factor of about 5 to 7 MIPS, or about like the 68000 in and Amiga. ???? The GPU can easily be used to perform per-raster operations, complex rendering, collision detection, bit manipulation, etc.

* Horizontal and vertical scroll registers with page support (similar to the NES). Each scroll register is byte and can scroll the screen from 0-255 pixels. Using the two “page bits”, the name table can be expanded in the horizontal and/or vertical directions. This allows for up to a 64×60 virtual tile map, with a 32×30 window (i.e. the screen), to be scrolled smoothly at the pixel level just by changing a single VDP register.

* All 32 sprites can be displayed on the same scan line. The 4-sprite maximum on a horizontal line limitation was removed. The maximum number of displayable sprites is also controlled by a new VDP register and can be programmatically set between 1 and 31 (31 is the *number* of the sprite that is the maximum, and sprites are number 0 to 31 for a total of 32).

* Removed the VDP “speed limit”, so you can not over run reading or writing to the F18A. The F18A’s internal state machines run at 100MHz, so they can easily keep up with the host system.

* 80-column mode (of course ???? ) The blink and inverse colors were not implemented. However, the text modes can use the enhanced tile features, so you can have colored text, sprite, and the bitmap layer in 40 or 80 column text modes.

* 64 programmable 12-bit color registers, which means a 4096 color palette.

* 30-row mode, inspired by the NES. GM1 can now be 32×24 tiles or 32×30 tiles (256×240 resolution).

* A real bitmap layer with up to 4 colors per pixel (2-bit color). This is not a video *mode*, the bitmap layer is available in all modes. The bitmap layer can have its width and height set from 1 to 255 so it is very efficient with memory use. The X,Y location for the bitmap layer can also be set, as well as priority over the tile layer and transparency.

* Enhanced attributes for tiles and sprites. Each tile or sprite can flip their pattern on the x and/or y axis, specify a palette to use, and tiles can set priority over sprites (on a per tile bases), as well as allowing color 0 to be shown or treated as transparent.

* Each sprite can set its own 8×8 or 16×16 size independently.

* Sprites can be “linked”, which allows you to move multiple sprites by updating just one sprite’s coordinates.

* 1-bit, 2-bit, and 3-bit color modes for tiles and sprites, which means 2, 4, or 8 colors for tiles and sprites. Tiles and sprites can set their color depth independently.

* A “fixed” tile map that allows individual tiles to not be affected by scrolling.

* Two 32-bit 100MHz counters, one dedicated to the GPU, the other for the host CPU. The counter can be initialized to a specific, single stepped, or set to free run.

* Two 32-bit 100MHz Linear Feedback Shift Register (LFSR) random number generators, one dedicated to the GPU, the other for the host CPU. The RNG can be seeded, single stepped, or set to free run.

* Programmable horizontal scan line interrupt.

* Read access to all VDP registers.

Par Grauw

Ascended (10679)

Portrait de Grauw

18-09-2019, 14:16

Why would I ever program for this though, when we already have the V9938, V9958 and V9990 widespread and underutilised as is.

Par gdx

Enlighted (5996)

Portrait de gdx

18-09-2019, 12:48

What could be interesting is make a replacement VDP compatible V9958 and/or Sega Master System, And an HDMI video output also why not. The too specific improvements are not really interesting.

Par frederic.markus

Expert (82)

Portrait de frederic.markus

18-09-2019, 16:39

I wouldn't mind a patch removing all slow downs and blink in all Konami games...

Par iamweasel2

Paladin (708)

Portrait de iamweasel2

18-09-2019, 18:46

erpirao wrote:

ok, we do an advanced fpga, for what?
it would not be more useful to integrate a V9990 + 9958 into an fpga ?, so you would have a fixed user base, and not further disperse the MSX community.
Come on, I think it would be more useful a fpga that makes 9990 (or master system vdp), than a new one.
But it's just an opinion

I agree. We don't need another new VDP that has no software at all to use with. We have V9990 for many years, it is now starting to be really used by developers, it is a retro VDP, and rumour has it was meant to be the VDP of Turbo-R.

It would be great to have it in a MSX FPGA integrated with V9958. Smile

Par iamweasel2

Paladin (708)

Portrait de iamweasel2

18-09-2019, 18:53

[Sorry, wrong post]

Par frederic.markus

Expert (82)

Portrait de frederic.markus

18-09-2019, 20:00

My point is that if you are going to redo a vdp, at least remove stuff that make games a pain to look at like sprite blinking...

Par PingPong

Prophet (4086)

Portrait de PingPong

18-09-2019, 22:11

Problem with a V9990 FPGA is that this chip is somewhat unknown. even the most accurate emulator (openMSX) does emulate it incorrectly. So a FPGA V9990 would be more inaccurate than other vdps.
Even the V9958 is not known in depth, for example, how does the horizontal scroll registers influence vram timing?

Par erpirao

Paragon (1304)

Portrait de erpirao

19-09-2019, 18:51

if we want to make a powerful vdp, you don't have to eat your head a lot.
The x68000 has been recently implemented in an fpga, it would be to take that VDP, integrate it into an fpga, and put it in an MSX cartridge.
but I repeat, and what do we do with the ones we already have?

Par frederic.markus

Expert (82)

Portrait de frederic.markus

19-09-2019, 19:02

And I repeat, just clone the ones we have and remove sprite blinking. And yes, the x68000 is one of may favorite machines Smile

Page 2/3
1 | | 3