O: P96 prodano

Takže podraží, či se zruší?

O: P96 prodano

Diky za zpravu... opravte mne, jestli se mylim, ale mimo OS4 je tohle asi naprosto minoritni zprava, ne? Ja nikdy P96 nevidel, jenom ve WinUAE.

O: P96 prodano

Bohuzel se mýlíš. Vampire nebo ty nové FPGA grafické karty jsou na P96 závisle ...

O: P96 prodano

Ale já z toho nechápu zda ovladače postavené na UAE, jsou košér nebo ne a tudíž mohou být v budoucnu napadeny ohledně licence..

O: P96 prodano

Kupujou to, protože ví, že Vampír je budoucnost a takhle jim z toho něco kápne.

O: P96 prodano

Tak podle nejnovejsiho vyjadreni Jense Hyperion neni schpen poskytnout mu co slibili, takze je vsechno zase trosku jinak a Jens zacne (jakmile se prezene napor vyvolany C64 Reloaded MK2) nabizet aktualizovany balik Picasso v modu Zaplat kolik chces (pravdepodobne s nejakou zakladni nizkou cenou)

O: P96 prodano

P96 v2.4.3




PS: zaujala mne veta "There's also good news from Cloanto: During a dinner that was organized by the organizer of the Amiga34 show, Michael Battilana said among witnesses.." )

O: P96 prodano

Je ta věta nějak vytržená z kontextu? Protože moc smysl nedává.

EDIT: Už to chápu, přečetl jsem si to celé na webu. Tak hlavně, že to bylo mezi svědky

P96 v3.0
iComp (ale hlavne Thomas Richter) dokoncil novou verzi RTG ovladacu P96. Protoze novinek je spousta, nova verze nebyla pojmenovana 2.5.0 jak bylo drive oznameno, ale rovnou 3.0.
Ti kdo si koupili aktualizaci P96 pred mene nez 12 mesici maji update k dispozici zdarma.

Zmeny ve zkratce
Za nejvetsi vylepseni autori povazuji pridani moznosti stahovani obrazovky jako zname z nativni grafiky. Ma to sice nejaka ta omezeni – pouze dve obrazovky a musi byt ve stejnem grafickem modu.
Nove ovladace pro CVisionPPC a BVisionPPC ktere podporuji nasledujici graficke formaty – chunky 8 bit, 16 bit RGB, 16 Bit RGB PC, 16 bit BGR PC, 24 bit RGB, 24 bit BGR, 32 bit RGBA, 32 bit BGRA, 32 bit ARGB and 32 bit ABGR.
Opravena spousta chyb
Příprava pro beh pod AmigaOS3.2

podrobneji zde https://www.a1k.org/forum/index.php?...5#post-1422922

P96 3.1.0 prinasi nektere zajimave novinky

- A new feature: Multi-monitor support. Thus, if you want to use native video and graphics card output displayed on two monitors, or have more than two graphics cards, this update has something new to offer. Tested at home with two graphics cards, two monitors and one TV.

- An all-remade CVision3D driver that addresses many of the problems the older driver has, including some performance improvements in 32bit modes, and new modes as well. If you have read the "Rumgevirge" thread at a1k.org, you already have an idea what changed (a lot). The S3 chip on this card has really some "issues" and it was unusually hard to get the diva tamed.

- A minor bugfix of the CVisionPPC driver.

- A larger bugfix of the Pixel64 driver.

- A lot of minor bugs in the core library.

+ par poznamek k pouziti vice monitoru

Tak to je mazec. Další info i možnost stažení je u Jense. Pokud máte koupenou předchozí licenci, upgrade je zdarma.

P96 3.2.0

The major news is that ZZ9000 and UAE support now "palette switching", which means that there will be no longer false colors if two chunky color screens are shown at the same time. Unfortunately, classic VGA chipsets do not support it, thus the ZZ9000 is the only card that profits from this feature.

Full change log:

• P96 supports now a new feature for graphics hardware, dual palette support. On such hardware, the palette can be changed mid-screen, allowing to display two 8-bit chunky screens on the same view. This avoids false-color defects on dragged screens on supported hardware. Currently, only the ZZ9000 and UAE emulation support this mode. Note that dual palette is not a feature a typical VGA chipset would be able to offer, i.e. all legacy graphics cards are not able to offer it.
• A LoadView(NULL) will now re-enable bitplane and sprite DMA as P96 disables them if a non-native screen is displayed.
• The CGfx emulation returned inconsistent results for the depth of various modes, in particular one of the changes in 3.1.2 broke NetSurf. The latter change was reverted, and the depth values were harmonized.
• The CVisionPPC driver now also initializes the P5 PCI bridge, using the data from the ConfigDevs in the expansion database if some are found, or otherwise using some default values. Initializing the PCI bridge may be necessary if some tools removed the P5 firmware and thus leave the CVisionPPC uninitialized.
• The CVisionPPC driver accepts now a new tooltype "MEMORYTYPE". Unfortunately, the CVisionPPC was manufactured with two types of video RAM that require slightly different settings. In case your card does not work with the default setting, add the tooltype "MEMORYTYPE=Old" to the CVisionPPC monitor icon and the driver will switch to the older memory configuration. The default is "MEMORYTYPE=New".
• LoadView() did not use the same logic when restoring an RTG view from a non-intuition view and thus might have sorted viewports (aka screens) incorrectly. Now LoadView() and MrgCop() are based on the same lower-level function, ensuring that both functions operate alike.
• While not advisable at all, P96 allows applications to pre-allocate a native bitmap and use this native bitmap as bitmap of a screen to be opened. If this happens, P96 converts planar bitmap data to the chunky VGA representation as soon as the bitmap is loaded to the board. While this is not at all new, some applications still attempt to render into this (now off-screen) bitmap with the blitter as the bitmap is (correctly so) reported as a "standard planar bitmap" by GetBitmapAttr(). P96 now detects this particular (mis-)use of planar bitmaps as backing store for chunky bitmaps and reports them as "non-standard", which helps some applications to avoid blitting by native hardware. Long story short: Don't do that - let intuition allocate bitmaps for you.
• BltBitMap(), BltMaskBitMap(), BitmapScale() and SwapBitsRastPortClipRect() have been prepared to allow even bitmaps with non-compatible aperture settings on the board such that the P96 management no longer has to through non-compatible bitmaps off the board. While some support for incompatible bitmaps was already present in former releases of P96, support was incomplete and therefore disabled. Re-enabling it may improve compatibility to some applications that assume that their bitmaps always stays on the board - which was actually never guaranteed or ensured.
• The ENV:Picasso96/DirectColorMask setting was not working, and confused with the debug setting.
• The BltBitMap function with DirectColorMask=YES did not work correctly for the minterm TRUE = 0xf0.
• When blitting to a true/hi-color bitplane with a mask, the mask was used inverted.
• When blitting with DirectColorMask set to Yes to a true/hi-color bitplane, the mask was used incorrectly. The code performs now a (albeit slow) inverse palette lookup, then applies the blit with the correct mask, then blits the result back. Needless to say, this is slow, but correct. Set DirectColorMask to No to get the speedy default operation.
• BltMaskBitMapRastPort() did not support all combinations of bitmap types and all minterms. Now even blitting from direct color to planar bitmaps work, and some minterms can be accelerated in case the source or the mask is not included.
• BitMapScale() did not respect the depths of the source and destination bitmap and could have scaled data in the source bitmap that was not meant to be part of the bitmap in first place.
• BitMapScale() did not reset the temporary bitplane when scaling from a direct color bitplane to a chunky bitplane with a depth less than 8.
• Blitting from a on-board planar bitplane to a chunky or true-color bitplane did not work at all and could have crashed the machine.
• SwapBitsRastPortClipRect() did not work with all bitmap type combinations, this was fixed. Note that the call should be avoided anyhow as it can be quite slow and may cause visual disturbance.
• Due to a timing issue of the GD5446, the PicassoIV scrolled the lower part of a split-screen along with the upper part. This was fixed.
• Even though not documented, the GD5446 in the PicassoIV supports 32bit ARGB modes, which were enabled.
• In case a system bitmap, as for example for the flicker fixer, was allocated with an incompatible bitmap on board, the code forgot to set the board info RGB Format, and thus left the board memory managment in an inconsistent state.
• Another undocumented feature of the GD5446 is that the chip actually supports the hardware sprite on top of planar memory. Adressing it is a bit tricky, but the driver now supports this. Thus, there is no need for a soft sprite for this particular board anymore.
• The same trick that allows hardware sprites on planar also works on the GD5434, i.e. the Piccolo64 and related boards, and for that reason, the driver also received an update.
• The GD5446/PicassoIV video and memory windows are now temporarily disabled while screen dragging is active. The hardware video overlay does unfortunately not respect the screen split position.
• The PicassoIV GRANTDIRECTACCESS flag was broken on Z-II systems as its absence enabled all blits, even those that require an apperture change. Instead, it should have disabled screen modes that require an aperture change.
• The PicassoIV check for compatible modes on Z-II systems checked the wrong register and could have returned incorrect results.
• If the mode of the front bitmap was taller than the height of the back bitmap when screen dragging, some junk could have leaked through at the bottom of the back bitmap. This was fixed by allocating the back bitmap at least as tall as the height of the front mode.
• The PicassoIV flicker fixer did not turn off a potential screen splitting when enabled.
• The PIV memory window (and likely the video window) do not work well with double scan modes due to a hardware problem of the Cirrus chip. Vertical interpolation also causes strange effects and is therefore turned off if double scan is enabled.
• The PIV 32 bit true color modes of the PIV do not seem to allow overlays, and create strange artefacts. Overlays on 32-bit screens are disabled now.
• BltMaskBitMapRastPort() on planar planes received a special case, speeding up the function somewhat by avoiding the typical double-xor triple-blit, which also avoids flicker for Bobs, e.g. workbench icons, when moved across a planar screen. The special case source plane = NULL also received a special case for planar blits. For chunky blits, the typical cookie-cut masked blit is already speed up.
• When migrating bitmaps off the card, P96 now migrates the least recently used bitmap first. This helps double buffering applications to keep both their front and their back buffers on the board.
• On some unlucky coincidence, the intuition V40 bitmap allocation hack that allows old versions of intuition to open an RTG screen could get triggered by accident by applications as well. The whole v40 hack has been reworked and made more carefully. Note that intuition versions beyond v47 (Os 3.2) are not affected as intuition passes the P96 tags into AllocBitMap() anyhow.
• Fixed a bug in BltMaskBitMapRastPort() which picked the wrong source if the blitter was disabled and the byte-offset into the source bitplane was larger than 64K.

A follow-up on the 3.2.0 release.

Another thing that is new is that the release allows now cards to hold bitmaps with incompatible apertures on board simultaneously. This is quite abstract, so I need to explain a bit what all that means. The consequences are hopefully improved compatibility.

So what's an aperture? That's a way how the CPU sees the memory on the graphics board. The VGA chipsets are typically designed for PCs and their little-endian architecture, which implies that modes such as 32 bit true-color are stored in "reverse order", with "blue" as first component, i.e. as "BGRA", and with hi-color modes with the bits somehow weirdly interleaved, with green spread over two words in a most inconvenient way.

To compensate for that, many graphic cards can provide multiple "apertures", by a small logic that sits between the Zorro bus of the system and the RAM on the board. This logic can either pass data through unaltered, or perform a byte-swap for word-accesses, or a byte-access for long-word accesses, such that "BGRA" becomes the more convenient "RGBA", and the weird interleaving of the 16-bit PC hi-color mode becomes a more canonical RGB with green populating adjacent bits instead of spreading them in a most inconvenient way.

Problem is: If the aperture changes, the "view" on the stored data in the video RAM changes, even if the RAM contents itself remains identical. Thus, if I blit between an ARGB and a BGRA bitmap, I would need to re-interpret the bytes as the two bitmaps use a different aperture setting. What P96 did before is that it threw bitmaps with incompaible aperture settings "off the board", i.e. ARGB and BGRA could not co-exist at the same time.

With 3.2.0, things change, and they can exist at the same time, but that means that blitting between them needs to be aware of the problem that the two bitmaps use incompatible apertures. Thus, the entire blitting logic canged and was made aware of aperture-switches, in particular if such switches are needed between blits of two incompatible bitmaps.

Thus, the entire blitting logic was improved. While at it, many improvements were also made on the "masked" blitting, i.e. "BlitMaskBitMapRastPort", how the function is called on the Os level. It takes a source bitmap, and blits that to the target, affecting only those pixels which are set to 1 in a third "mask" bitplane.

This logic only supported two minterms, namely "blit through mask" and "blit inverse through mask", which are the two documented modes by the Os. However, there are more modes available (16 in total), and they are not documented, but they work on the Os level as the modes just install the "min term" into the amiga blitter. Now, P96 is also aware of all the undocumented minterms, and emulates them correctly with the CPU.

There is a third improvement in that area, namely the "planar" emulation of this masked blit. This emulation is used by the "Native" driver of P96, if blitting on native Amiga bitplanes is emulated by P96. This emulation used to flicker quite a bit since it emulated the native masked blit by a "double xor" trick which, for a short time, destroys the destination. This particular blit was now hand-optimized to avoid the flicker (and also to speed it up a bit).

Last, there was one serious bug in the masked chunky blit, thankfully detected by Christian Sauer: I the offset into the source bitmap was larger than 64K, the blit picked up the wrong data in the CPU emulation, resulting in wrong graphics being blitted. This was due to a wrongly sized instruction which only added the 16 lower bits of an offset to obtain the target address. This bug must have been there since at least version 2.xx something of P96, and was now finally fixed.

CVisionPPC, BVisionPPC

Unfortunately, there are so many different versions of the firmware around that it is hard to keep an overview. Some versions of the firmware inject the addresses of the vga chip interface and the vga memory into the autoconfig database, such that CPU libraries can "drill a hole" into the MMU mapping in the right places as part of the usual MMU table setup. Some versions (probably earlier versions) don't, and also leave the chip unconfigured.

P96 did not succeed in enabling such earlier releases of the cards and depended on the boot firmware of performing this step, but this is no longer the case now. The cvisionppc card init function now detects such unconfigured chips, and performs the necessary initialization steps itself. For that, it needs access to the mmu.library (No, I do not touch the MMU manually, this does not make sense anymore) to create the correct mapping for the VGA memory and the chipset registers.

This fix is mainly due to Brian Carpignano, which helped me hunting the issue down. P96 should now hopefully work on all revisions of the cvisionppc and bvisionppc graphic cards.

Unfortunatey, there are more variations of the cvisionppc and bvisionppc.... P5 also equipped them with different memory types that require slightly different configurations, and it is not quite clear on how to detect the proper memory type of the VGA video RAM. Thus, if the default RAM configuration does not work or artefacts show up, try adding the tool type "MEMORYTYPE=Old" to the cvisionppc monitor icon.

Keď sme už u toho, tak som nahodil (Amikit 11.5 betu pre Win) na moju A1200 s BPPC a BVision a použil som P96v3.1 a fahci to celkom slušne. 😁

Autor si nepreje abych Amikit pouzival, tak ho nepouzivam.