P96 3.0.0 (and later) news and support

[gdonner]

Yes, many thanks for these updates!

[deluxe1260]

With a new version of P96(3.2.3) something is not functioning correctly. When I run an app which opens in dblPAL mode, that app just freezes. Then I have to switch back to workbench screen(PAL) with amiga-m, and pull it down with a mouse, to see that app in background(which is now displayed in PAL of course and working) to quit it.
That issue is only related with dblPAL mode. Others(PAL, dblNTSC, Multiscan,..) do not have this issue. Native driver on or off…
I tested it also with previous version of P96(3.2.2.) and is working ok

[Thomas Richter]

Yes, thank you, I know, I'm on it. Actually, I believe I have a fix already, but in order to get a beta, please leave a message at the iComp forum. I can only provide betas through official channels.

[Thomas Richter]

Somehwat more background on the latest release: Bitmap locking. Well, both P96 and CGfx provide a mechanism to get direct access to bitmaps for direct CPU rendering - this is called Bitmap locking. Once a bitmap is locked, P96 is no longer supposed to touch it or move it. Unfortunately, this only worked half the way. P96 clearly locked its internal structures by semaphores, but if the calling task was allocating a bitmap itself while holding the lock, the locked bitmap could have been migrated off-video RAM anyhow, invalidating any pointers on the memory. A related race condition appeared while blitting through a mask. As the mask is planar by definition of the Os interface, but the graphic chips require chunky bitmaps, the renderer requires temporary graphics memory. This memory allocation could migrate other bitmaps off-board in low memory situations, and in worst case the bitmaps to draw, or the bitmap to draw on. Then, P96Mode duplicated one pointer... actually, a pointer to the name of the mode being worked on. Due to the way how the legacy P96Mode program worked, this was never a problem, but now as the mode string is updated more frequently, it caused a problem because this duplicated pointer could have been released more than once, causing a nice "memory-inconsistent" 81000009 software failure. Bummer! This was actually a pretty old bug that never manifested itself until some code was updated. Then, there was an issue with the line drawer, in particular if the line has a pattern. In such a case, a lot of care needs to be taken to ensure that the pattern continues correctly if parts of the line are hidden under another window (actually layer), and the code needs to be aware of how many pixels are under the hidden window to continue the line pattern at the right spot. Actually, this particular defect I already fixed like 20 years ago, but due to some mischief, it sneaked in again by merging various sources (my archive, the original archive by Alex and Tobias) and thus was re-introduced again. A clear "data vue" feeling on my end - "I had fixed this particular bug before!". One minor glitch was that P96 forcefully redrew the sprite when switching screens. For most graphics cards, just replacing the sprite pattern by an identical sprite pattern does nothing bad, it is just overhead. However, on the CVisionPPC/Permedia2 chip, accessing the sprite buffer interferes with the DMA logic of the Chip, and the CPU accesses are visible on the screen as "glitches". If the 68K accesses the video RAM, the Permedia2 chip cannot, and thus fetches invalid data. Now P96 avoids redrawing the sprite, unless it really has to.

[Swe_Kryten2x4b]

Originally Posted by Thomas Richter

No, but there is a chance to find out. Please install SegTracker (from Aminet) and LockSmith (also from Aminet), and connect your system with a 0-modem cable to another machine at 9600 8N1, then, when it locks up, press the "magic key" of locksmith, which is "Esc" by default, and report what comes through the serial terminal. Thank you.

Late (new) answer...I never got around to getting a null-modem adapter to check what output those programs would give me. Mostly because it was very hard to find a usb-to-serial adapter that wouldn't take ages to arrive...still, it doesn't seem to be necessary anymore.

I'm not sure if it is one of the recent updates to P96, the new version of the vampiregfx driver, the new version of the vampire-core, or some combination that did it, but for now at least it works. About 10 coldboots so far with no lock-ups.

So now it works as I want it to. I just hope it won't start acting up again or I'll be really confused. Well, more than usual that is...

[Leon Besson]

Hi Budros!

Hopefully I’m posting this in the right place?

Just purchased P96 from icomp and have just installed it on the following;

1200 TX+
Blizzard 1260 + SCSI MKIV
Voodoo 4

All Elbox software up to date pci.library 13.10 etc……..

On starting up Ibrowse 2.5.5 either with png or ilbm the icons are all scrambled and not correctly showing. When loading EAB the graphics do this as well but then correct themselves.

Anyone else getting this? If so what’s the fix?

Have already tried reinstalling Ibrowse and using voodoo driver from Elbox as P96 3.2.2 doesn’t include one.

[Thomas Richter]

Originally Posted by Leon Besson

Hi Budros!

Hopefully I’m posting this in the right place?

Not quite. The right place is either the iComp forum, where you can check for the latest beta. However, blitting is up to the driver to implement, so I suggest to talk to Elbox for an update of their driver. The driver is not part of P96, but Elbox property.

[Leon Besson]

Originally Posted by Thomas Richter

Not quite. The right place is either the iComp forum, where you can check for the latest beta. However, blitting is up to the driver to implement, so I suggest to talk to Elbox for an update of their driver. The driver is not part of P96, but Elbox property.

Thanks Thomas

[Thomas Richter]

As of today, a new release (3.2.4) is available at the iComp store and can be downloaded from your order history if you still have an active license. Or you can buy a new version if you don't.

This is a small bugfix release with a couple of minor fixes.

- The S3Virge chip on the CVision3D card has an interesting hardware defect in the sense that it hicks up and generates faulty data if the blit width has particular values. The new virge driver contains now a workaround for this problem.
- If screens driven by the native Amiga chipset were active while P96 was loaded, P96 unfortunately loaded the VTOTAL register of Denise with nonsense values, and by that trashed screens in enhanced modes such as Productivity or DblPAL.
- If a masked blit was made from an interleaved planar bitplane to a P96 bitmap, P96 did not compute the modulo value of the mask correctly and hence might have caused trashed screens.
- If a masked blit was hardware accelerated, and the target screen did not use the full bitdepth of the target mode, then P96 might have created some junk on the screen.

[Thomas Richter]

The remaining news on 3.2.4 relate to better support for a particular graphics card, namely the "Merlin". Before I continue, a disclaimer:

The Merlin card was never developed to a stable product and was sold before its design was finished. This causes a lot of instabilities and compatibility issues, and not all of them can be addressed by a board upgrade, neither by software. Thus, if you have a Merlin, I wouldn't invest money just for this release of P96, it cannot do miracles. It is getting more robust, but that still doesn't mean that the card works flawlessly. Better safe the money for a working card rather than an engineering prototype such as the Merlin.

So, now for the Merlin specific fixes, keeping the above restrictions in mind:

- Due to bad routing, any clock frequency larger than 80Mhz cannot be transmitted from the clock generator to the VGA chip on the board. To this end, P96 now disables larger pixel clocks. Note that this also blocks some pixel clocks below 80Mhz as they are generated by dividing down the incoming clock within the VGA chip to the target frequency. For example, one could generate a pixel clock of 65Mhz by configuring the clock generator to 130Mhz and dividing it down by a factor of 2 in the VGA chip, but that doesn't work since the 130MHz never reach the chip. Instead routing works like an antenna and blows the 130Mhz (FM radio frequency) into the ether. If you really really want to try (as in "shoot yourself into the foot") you can set the tooltype "OVERCLOCK=Yes" in the Merlin monitor icon, which unlocks all pixel clocks. Again, not recommended, and will likely not work in any way you find useful.

- Due to another hardware problem, register writes from the CPU into the VGA chip are sometimes altered, either reaching the wrong register, or writing the wrong data. This can lead to serious misconfigurations of the chip that can hang the card, and with that the host system completely. There is nothing that can be done against this problem, it is a board design issue. Such spontaneous hangs often occur when reconfiguring the card for another graphic mode as this requires loading a lot of registers and hence enlarging the probability of a "bad write". The risk can be minimized by blanking the screen while loading the registers, which is now what P96 does, but it cannot be eliminated completely.

- One important register is the bank-switching register that maps the Merlin blitter into the VGA memory area. This register needs to be loaded relatively often when blitting on the screen. To minimize the risk of bad blitting, the chipset driver contains now a particular "paranoia" logic that checks the register value after having loaded it, and it repeats the load if the written value is different from the intended value. This makes blitting (moderately) safe. At least, writing on the screen hasn't crashed the card here after some hours of testing. Thus, as long as you don't change the screen mode, you are "probably ok".

- There is finally one new feature of the Merlin card, namely "memory overlays", aka "PIP" aka "Picture in Picture". This is natively supported by the VGA chipset on the board (the TsengET4000w32), though it is unfortunately only moderately useful because the mode of the memory window needs to be identical to the mode of the screen it operates on. Thus, you can only have a "chunky overlay" on a chunky screen, or a true-color overlay on a true-color screen. There is no such thing (as on the S3 or P-IV) as a hi-color or YUV overlay on a chunky screen, unfortunately. Thus, the PIP feature is not "quite as useful" as it sounds.

This restriction is due to the Tseng chip lacking an internal RAM-DAC, all graphic data is interpreted outside of the Tseng chip in a separate chip, and this separate chip is unaware of the intended mode of the overlay as it only sees dumb data from the VGA chip.

Similarly, there is no transparency support for the overlay, which means that the overlay needs to be disabled if the window containing the overlay is clipped or partially occluded. It neither works with a softsprite as the softsprite cannot appear "on top" of the overlay. It would need to be transparent behind the softsprite, which is a feature the hardware does not support.

Luckily, the Merlin card has a hardware sprite which is generated by the RAMDAC, and the hardware sprite works nicely with the overlay as it is generated by a different logic.

[Phantasm]

Originally Posted by Thomas Richter

As of today, a new release (3.2.4) is available at the iComp store and can be downloaded from your order history if you still have an active license. Or you can buy a new version if you don't.

This is a small bugfix release with a couple of minor fixes.

- The S3Virge chip on the CVision3D card has an interesting hardware defect in the sense that it hicks up and generates faulty data if the blit width has particular values. The new virge driver contains now a workaround for this problem.
- If screens driven by the native Amiga chipset were active while P96 was loaded, P96 unfortunately loaded the VTOTAL register of Denise with nonsense values, and by that trashed screens in enhanced modes such as Productivity or DblPAL.
- If a masked blit was made from an interleaved planar bitplane to a P96 bitmap, P96 did not compute the modulo value of the mask correctly and hence might have caused trashed screens.
- If a masked blit was hardware accelerated, and the target screen did not use the full bitdepth of the target mode, then P96 might have created some junk on the screen.

Great news... Resource now works correctly when running P96 modes (as long as you stick to 8 bit colour depth) THANKS!

[hexaae]

Originally Posted by Phantasm

Great news... Resource now works correctly when running P96 modes (as long as you stick to 8 bit colour depth) THANKS!

Try also http://m68k.aminet.net/package/util/cdity/ModePro to force screen modes and/or bitmap screens to let you keep 24/32bit for Workbench and correctly handle some nasty multitasking programs/games...

[Leon Besson]

So this is interesting. I have resorted to uninstalling P96 v3 back to V2.1 and everything is back to normal. The only issues I’m Seeing with the Voodoo and P96 v3+ is displaying with Ibrowse such as the buttons to move forward and backwards as well as graphics in web pages looking torn and broken up. Anything else such as the RTG workbench modes etc.. is fine. Will contact Elbox on their view.

[jbenam]

Originally Posted by Leon Besson

Will contact Elbox on their view.

They will tell you that this has been fixed in Mediator IV and that you should buy one. And no, they can't sell you just 2 upgraded CPLDs for yours, that would be too easy and so not profitable for them - and if you dare to ask, they will just stop answering to your emails

Who cares about customers when you can just sell them more of the same?

(One angry Elbox customer)

[Thomas Richter]

All I can say from my side is that I didn't change the driver interface, or at least I'm not aware of having made a change. All the legacy P96 drivers (even those from 2.x) continued to work. What I can confirm is that there is some issue with the blitter interface of the elbox cards because you can prevent the problems by setting "NOBLITTER=Yes", which renders completely by the CPU.

Given that elbox did not have access to the driver API documentation (another long story), I can only guess that their driver only works by accident in 2.x, making some assumptions on the interface that were never documented, or depending on some internals that are not part of the interface.

Thus, I wouldn't really know what to do about this.

[Leon Besson]

Originally Posted by Thomas Richter

All I can say from my side is that I didn't change the driver interface, or at least I'm not aware of having made a change. All the legacy P96 drivers (even those from 2.x) continued to work. What I can confirm is that there is some issue with the blitter interface of the elbox cards because you can prevent the problems by setting "NOBLITTER=Yes", which renders completely by the CPU.

Given that elbox did not have access to the driver API documentation (another long story), I can only guess that their driver only works by accident in 2.x, making some assumptions on the interface that were never documented, or depending on some internals that are not part of the interface.

Thus, I wouldn't really know what to do about this.

No worries Thomas. I know it’s a major headache coding stuff around parts you may not own. I have kept a copy of P96 V3 on my test tower with a Mediator TX and Voodoo 4. When I get a bit of time will have a play around to see if it’s something I’m not doing perhaps? On a side note I haven’t tried by installing V 3+ From scratch, but only done an upgrade from an already installed and working V 2.1B? So maybe something in the upgrade process is giving weird issues? Anyways will keep this thread updated

[Leon Besson]

Originally Posted by jbenam

They will tell you that this has been fixed in Mediator IV and that you should buy one. And no, they can't sell you just 2 upgraded CPLDs for yours, that would be too easy and so not profitable for them - and if you dare to ask, they will just stop answering to your emails

Who cares about customers when you can just sell them more of the same?

(One angry Elbox customer)

Have both a 1200 TX and their newer 1200 TX+ solutions. So they can stick it where the sun don’t shine if they try that on

[gerul]

Hi
A4000, CV64/3D, OS 3.2.1.
After installing last P96 it is impossible to launch Music-X 2.0. One second after switching screen (Music-X screen appears but none of the interface is visible, except title bar and some empty requester window) Amiga is resetting to red Guru.
Second issue, with resolutions 1024x768 and higher, when I scroll screen or do something CPU demanding, I see artefacts on the right side of the screen. With 800x600 everything is OK.
Same hardware with CGX installed, everything works perfectly.

Is it bug or some tooltip switch is required to make P96 usable?

[pcotter]

Hi,
anyone using TBClock with latest picasso?
it does not shows with it.
http://aminet.net/package/util/time/TBClock
Thanks

[Thomas Richter]

Originally Posted by gerul

A4000, CV64/3D, OS 3.2.1.

Please note that the right place to report bugs is the icomp page because you can also get there (potentially) new versions there, after providing proof of your purchase.



Second, is that a CVision3D or a CVision64? Those two are very different. Third, which version of P96 is that? The CyberVision3D driver changed and improved significantly in the latest versions.

This said, the above program may hijack a hardware interrupt for midi, potentially the same interrupt the CVision3D uses for its vertical blank interrupt. If the program would operate in a system friendly way, this problem would not appear. You can, however, instruct the driver not to use an interrupt by adding "INTERRUPT=No" to the tool type of the monitor icon (if that is a CVision3D).

Second, if a particular mode shows defects or issues, it always makes sense to use P96Mode to adjust it, probably moving the mode a bit, or lowering the pixel clock a bit.