P96 3.0.0 (and later) news and support

[Swe_Kryten2x4b]

First off, I'm not sure if this is a problem with the latest P96 (using v312) or the monitor driver for the vampire1200 or some weird combination.
So bear with me.

Prelimanarys first: I'm using a Vampire 1200, on Wb 3.2 (kick 3.2 flashed into the vampire, somewhat custom with a pcmcia reset fix in "rom" but the
problem is there even with a stock 3.2) with core 2.13 and Saga-drivers 2.7 and Picasso 3.1.2. None of which has changed recently.

The other day the computer locked up completely when I booted it. I got the workbench (set to use a vampire gfx-mode), but the pointer refused to move.

I first thought it was my mouse that had given up the ghost but it worked just fine in early-startup and in failsafe mode.

When I copied the vampiregfx montor fresh from the archive it worked as it should again. So I thought it had somehow got corrupted, but no such luck.

As soon as I change two tooltypes to be what I want them to be, I get the lockup again. The lockup happens before the wbstartup programs get a chance to run btw.

The tooltypes in question are

NoSwitch=Yes
DisplayChain=NO

As well as RIGHT_OF=native to get p96screencx to work, but the lockup happens even without that one.

I didn't think of those at first when I got the first lock-up, ant not sure if the same problem is there in earlier revisions of either
the driver or p96. I've never tried the multiscreen setup until recently.

If I use the .info file without the altered tooltypes it always works. Although obviously without the features I want enabled.
If I boot with the original and then replaces it with a .info file with the altered tooltypes and resets, it works.

And I don't think it is a hardware problem. Everything else works as it should. I can run programs that require or take advantage of the vampire if present (such as riva or diablo), not to mention software that has no idea of what a vampire is but require or has been set to use a RTG-screen such as TVPaint, ScummVM, or photogenics. And since it works when I do a reset (after copying a altered .info file) I don't think it is my custom s-s that's the culprit either.

To sum up: if using the vampiregfx driver straight from the saga2.7 archive it always works, cold boot or not.
If I alter the tooltypes as above, it locks up on cold boot. If I use the original on cold-boot and then switches to the altered one and resets, it works.

Anyone with an idea what could be causing this? Because it is quite annoying and I have run out of ideas of where the problem might be. For now, the workaround is to not use those features but I'd really love to be able to.

[Thomas Richter]

Originally Posted by Swe_Kryten2x4b

Anyone with an idea what could be causing this? Because it is quite annoying and I have run out of ideas of where the problem might be. For now, the workaround is to not use those features but I'd really love to be able to.

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.

[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.

Thanks. I guess I need to find myself a 0-modem cable then...I haven't used one for at least a decade.

Not to mention a usb-to-serial adapter since the only computer I own with a serial port is the Amiga. Lucklly enough I know that one is working since there's a MIDI-interface there that works just fine.

Still, a question. The readme-file for locksmith mentions MuForce and MuGuardianAngel. It is not clear (at least not to me) whether locksmith and/or segtracker requires an MMU. If either or both does, I'm out of luck anyway since the vampire doesn't have one.

[Thomas Richter]

Neither do.

[Swe_Kryten2x4b]

Originally Posted by Thomas Richter

Neither do.

Excellent. I'll get back to you as soon as I've managed to find a cable to test with.

[Thomas Richter]

Just a few hours ago, a new release of P96 has been published, and you can get it from the iComp store as usual. Release 3.2.0 provides one new major feature for owners of the ZZ9000 card and UAE, improves compatibility and fixes all the issues that have been reported since then.

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.

I will provide more insight into other new features and bug fixes in the next days, but here is the 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.

Merry Christmas!

Thomas

[Thomas Richter]

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.

More improvements later...

Merry Christmas,

Thomas

[kamelito]

Nice, I suppose that the new minterms are described in the SDK?
Happy Xmas to all.

[spudje]

Awesome seeing new releases so close to the holidays. I read something of an issue with Picasso96 3.2.0 & AmigaOS 3.2.1 on a1k. But I couldn't fully understand it. Can someone: - Explain what the exact issue is?
- With which combination of hardware this occurs?
- What is missed when using AmigaOS graphics.library if v 3.2.0 is used instead of v3.2.1 as advised?

Thanks!

[Thomas Richter]

Actually, I do not plan to document them, as the original Os SDK neither documents them. Support for them is just there in case someone did not follow the Os SDK, it's Amiga after all. It is not hard to infer the result of the other minterms, though, if you know how the blitter works and how BlitMaskBitMapRastPort() works.

[Thomas Richter]

Originally Posted by spudje

Can someone: - Explain what the exact issue is?
- With which combination of hardware this occurs?
- What is missed when using AmigaOS graphics.library if v 3.2.0 is used instead of v3.2.1 as advised?

The issue seems to be that some defect in the graphics.library display info database causes crashes upon installing new modes into it, such as loading a monitor driver, or loading P96. Which is ironic since the 3.2.1 graphics.library attemted to fix an issue just there.


At this point, the details are unclear, but consequences are that P96 might crash upon loading with 3.2.1 graphics present, but works with 3.2.0 graphics present. Since the P96 code for installing monitor drivers did not change, it looks like a fix in the graphics code just created another issue.


All I can recommend at this time is to continue using the graphics.library that came with 3.2.0.

[coldacid]

I wasn't even aware that P96 and graphics.library 47.10 don't play well together. They seem to do nicely for me.

[gdonner]

Thomas, many thanks for this large update!

Merry Christmas to you as well--I trust you get a well-deserved break!

[Thomas Richter]

Some more news, which might be hidden in the big fixes list above. That's again on the CVisionPPC. 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.

(Maybe you now understand why I'm "a bit reserved" on P5 creations... it's all undocumented land, and not very well integrated into the system, with lots of variations and problems of its own).

[Pyromania]

So does that mean support for the very limited supply of products from the new Phase5 is out of the question?

[torsti76]

Originally Posted by Pyromania

So does that mean support for the very limited supply of products from the new Phase5 is out of the question?

What products from the new Phase5? The groundless ones? ;-)

[Thomas Richter]

Originally Posted by Pyromania

So does that mean support for the very limited supply of products from the new Phase5 is out of the question?

Oh no. For the currently existing product series, and at this time of the year, simple self-support is possible without my engagements, simply by opening the windows for a short while to let the hot air escape.

[torsti76]

Originally Posted by thomas richter

oh no. For the currently existing product series, and at this time of the year, simple self-support is possible without my engagements, simply by opening the windows for a short while to let the hot air escape.

:d :d :d

[Pyromania]

I was joking about the new Phase 5, I should have added a smily face.

[Acill]

Happy to see a new release again, but not so happy to see its release just after most of use have expired downloads from the previous release. I've now had to pay for this again. The last three times now have been forced to pay for it.