P96 3.0.0 (and later) news and support

[alexh]

Thanks for all your hard work.

Originally Posted by Thomas Richter

Unfortunately, as I do not have the flicker fixer (the VA2000CX), I cannot test this part

If Lukas will confirm this is the last version of the PCB design files for the VA2000CX Video slot board you could have one made. They look almost passive, some voltage level shifters and a pin header. (Plus another pin-header soldered to the VA2000 card). Look very easy to solder.

[Thomas Richter]

Sorry, had a defect in blitting rectangles in hi- and truecolor modes.

https://eab.abime.net/attachment.php...1&d=1704391017

[Thomas Richter]

A little bit of an update. There were still bugs in parsing the tooltypes for configuring the capture parameters of the card.

https://eab.abime.net/attachment.php...1&d=1704409033

There is one additional bonus: This version is also able to use the hardware blitter to move off-screen bitmaps to the screen and vice versa. This has the nice side effect that smart-refresh windows are now a lot smoother. This is something the reference driver did not do.

[klx300r]

Originally Posted by Thomas Richter

A little bit of an update. There were still bugs in parsing the tooltypes for configuring the capture parameters of the card.

https://eab.abime.net/attachment.php...1&d=1704409033

There is one additional bonus: This version is also able to use the hardware blitter to move off-screen bitmaps to the screen and vice versa. This has the nice side effect that smart-refresh windows are now a lot smoother. This is something the reference driver did not do.

wow thanks for this VA2000/CX2000 specific release Mine has been running awesome in my A4000 with OS3.2 the way it is with screen dragging so curious to see how this release compares...I'll be backing up my sys folder before messing around with this new version later today and will report back. If there's anything specific you want tested please let me know

[Thomas Richter]

Sorry, the card does not support screen dragging or panning with the current FPGA core. However, if there is someone out here with sufficient experience with Verilog and a Xilinx compiler license, I can tell you what you would need to do to make it support screen dragging and potentially panning.

Anyhow, the version will appear on Aminet in the next days. What I added was also to use the blitter to accelerate some parts of the mouse cursor drawing. I doubt this will make much of a difference, but let's make this as good as possible.

[klx300r]

@ ThoR


ok thanks for the clarification and hope someone can help you out

[Hedeon]

PPC PCI cards slow down with 50% using >2.5

[Thomas Richter]

I have no idea what this is supposed to mean. PPC is not supported, this is an 68K version. Neither was there ever a 2.5 release, the last 2.x release was 2.4.6. If you are looking for PPC, go for AmigaOs 4.0 and its version of P96.

[Hedeon]

It means that WarpOS PPC Warp3D is much slower when any of the newer versions of 68k P96 is installed. It halves the fps compared to 2.1 for the Voodoo. Sorry, was a bit brief because I thought you wouldn't react anyway seeing it impacts PPC on classic I can look further into it if you are interested to pinpoint the exact version which changed it. I suspect some interrupt issue maybe as we are talking PCI bus and different CPUs here.

[Thomas Richter]

P96 does not perform any 3D operations, that's all Warp3D. All P96 does is to provide a frame buffer and access to the GPU registers, and the rest is up to warp3D. If things are slower or different, then because you use a different graphics mode, most probably because you are using it with the wrong aperture setting as the cybervisionPPC has plenty.

Use the guide to see how to enable all modes, there is an environment setting for this, then select a suitable screen mode.

[pipper]

Could it be a cache setting issue? When did P96 start changing the cache settings for the cards memory region?

[Hedeon]

Maybe this makes it a little more clear? I am not talking about 3D operations per se, but that the fps went down a lot by just replacing the libs.

https://eab.abime.net/showpost.php?p...&postcount=156

[trixster]

I’d add that two other ppl tested this issue and saw the same reduction in speed, so it wasn’t just my system (DarrenHD and jkdsteve I think, can’t quite remember). I did start testing by uninstalling p96 each time and fully installing each new one but then realised the issue could be replicated just by swapping rtg.library.

[Thomas Richter]

Instead of speculating, why don't you just read my post above? Again, P96 *does not* perform any 3D rendering.

[Karlos]

@Thor

Warp3D contains two components. There's a 3D driver library component which has multiple chip implementations. These are independent of the RTG standard in use and rely on a second GFX component, which exists in P96 and CGX variants. The GFX component handles all aspects of vram memory allocation, bitmap locking, etc.

Depending on the config, Warp3D typically begins a drawing operation by locking bitmaps and potentially calling forbid and disable while hardware rendering is ongoing. So if there is any change to how bitmap allocation, locking, copying or pinning works, it could well have a significant impact.

[Thomas Richter]

Look, what is in particular wrong with the following algorithm:

1) Open up the P96 guide that comes with P96
2) Navigate in the guide to the entry named "FAQ - Frequently asked questions"
3) Navigate in the FAQ to the entry named "Warp3D is slow on the CVisionPPC"
4) Click on this link, and read it.

Please stop the pointless speculations. I have written this all down, providing even instructions.

[alexh]

Originally Posted by Thomas Richter

Sorry, the card does not support screen dragging or panning with the current FPGA core. However, if there is someone out here with sufficient experience with Verilog and a Xilinx compiler license, I can tell you what you would need to do to make it support screen dragging and potentially panning.

I don't own this card but I am a HDL programmer. A successful outcome would depend on a series of things (the original design complexity + design change complexity + FPGA capacity overhead + freetime).

There is a slim chance the VA2000's successor, the ZZ9000, has a design similar enough that the screen dragging / pan changes can be lifted from the ZZ9000 source with minimal changes.

We'd need to be sure that the VA2000's HDL here (tagged as v1.9) corresponds to the latest bitfile.

[Thomas Richter]

Lacking the tools, I cannot verify, but at least the population of the registers matches those of the hardware, so chances are quite high that this is the correct file. But experimenting without the hardware makes little sense.

[alexh]

Originally Posted by Thomas Richter

experimenting without the hardware makes little sense.

I do it every day. The hardware I'm designing doesn't exist yet.

I was offering to make the changes to the HDL and create the bitfile.

[Thomas Richter]

Well, here are a couple of suggestions (probably walk through step by step, I'm trying to sort them from easy to hard).

1) The clock generator. Apparently, from what I read in the sources, the clock generator can generate 40MHz, 75Mhz and 100Mhz, yet, it is currently only synthesized for 40/100 or 40/75. If possible, can you feed in another bit from the clock selection into the oscillator to provide more options for the pixel clock? Currently, the 100Mhz clock is too high to allow true-color, thus 1280x1024 in 32bpp does not work, though 1280x720 with 75Mhz might work in true-color with a 75Mhz clock.

2) The blitter has currently only a single pitch register. This is very annoying for blitting off-screen bitmaps that have usually a pitch different from the screen. Providing a separate "source pitch" register should be very straightforeward. Ideally, writing the pitch would set both the source and destination pitch (for backwards compatibility), though a separate write to the source pitch would be able overwrite it later.

3) The "line buffer". The current source has a line buffer for double-scan modes that is limited to 640 pixels. That limits double-scan modes to 640xX modes, though 1280x512 or 1024x384 modes following the typical Amiga hi-res 1:2 aspect ratio would be possible. I do not know, however, whether the spartan6 has sufficient block RAM for such a larger buffer, but you can try. (This should also relatively straight foreward).

3) Tricky: Panning support (also needed for screen dragging). The current operation of the code (as far as I understand it) is that it opens a page of the DRAM, fills a buffer, then pushes pixels out from that buffer to HDMI, until a watershed-level has been reached, then refills the buffer, independent of the screen pitch. That means that the screen pitch is frozen to the display width, which is undesirable for panning. Instead, screen pitch needs to be independent. That means that the RAM arbitration has to change. In particular, at the start of the horizontal blanking, the RAM page needs to be opened up again, and the fetch buffer of the RAM has to be refilled from the next row.
What P96 can deal with in general are screen pitches that are multiplies of powers of two, thus you can always start from the start of the RAM page at the beginning of a line if that is more convenient, though panning will require that video-out starts in the middle of the buffer. There was an error in the P96 2.x sources that prevented this pitch selection from working, but those have long been fixed.
(Historical remark: This is also pretty much how the INMOS chips implement panning - they fill the entire shift register at the start of the line, then define a "tap position" at which the vram shift register is emptied to the video output).
This is a very tricky one.

4) Once panning is working, screen dragging is an easy one. It just means having a single register that is compared to the line-Y position, and at that position, the pointer for fetching screen data is reset to zero, and the panning (the "tap position") is reset to zero. That is really all.

5) If there is still sufficient block RAM in the FPGA, a second palette would be helpful. The chip would switch from the primary palette to the secondary palette at the line compare position (see above). This avoids corrupt colors for screen-dragging of indexed color modes. P96 can deal with a secondary palette.

6) Very tricky: Change the video mode (from chunky to hi-color or similar) at the screen-split position. That means that the RAM arbitration would need to change mid-screen. This would allow to drag screens even of different modes. P96 can support that. Otherwise, screen dragging is limited to same-mode screens.

Anyhow, just giving you food for thought. If you do the Verilog, I can do the driver. Unfortunately, I have to admit the harder part is on your end. (-;