02.Mar.2022
iComp
|
RTG driver: P96 V3.2.4 released
Jens Schönfeld (individual Computers) schreibt:
"The new version addresses all issues that have been reported in our support forum - and a few more. As usual, the update is free for everyone who purchased a copy of P96 in the past 12 months. Just log in and re-download the file from your order history. Changes in release 3.2.4:
- Displaying native modes like DblPAL or productivity was broken in V3.2.3 - fixed.
- The S3Virge blitter has trouble with blits of a certain size that are avoided by this new version.
- Removed the manual MMU hack. Any MMU table modifications require now the availability of the mmu.library.
- The previous release broke the VBlank interrupt of graphics and might have loaded the VerticalTotal hardware register with nonsensical values.
- The S3Virge blitter has a bug and "freaks out" if one attempts to perform blits of particular widths. The Virge driver now adds a workaround by avoiding problematic bitmap widths.
- The S3Virge blitter can process at most 4064 bytes per row. Before, the limit was set to 4095 bytes, causing wrong blits on some large screens.
- BltMaskBitMapRastPort() did not work correctly if the target screen did not have the full depth, i.e. if a chunky mode was opened with a depth smaller than 8. This was another old bug left over from the 2.x release series.
- BltMaskBitMapRastPort() did not use the right modulo for the mask if the source bitmap was interleaved and planar and the destination bitmap was chunky or direct color. The mask was used correctly for interleaved or non-interleaved planar to planar blits.
- Users of the oMNiBus card beware! The card driver may use the TsengET4000W32 chip driver, even with earlier releases of the Tseng chip that do not include a blitter. In such cases, attempting to blit will fail or hang the system. To prevent usage of the (then non-present) blitter, set the tooltype NOBLITTER=Yes in the monitor icon of the oMNiBus monitor. Note that this is not a new restriction.
- Quite a number of improvements have been performed on the Merlin and TsengET4000w32 drivers as listed below, however please note that the Merlin card has a couple of serious hardware issues that cannot be worked around completely in software and that this card may hang or crash the system, despite our best attempts to avoid such problems. Even the Merlin board/GAL updates will not completely eliminate all of these issues. You should replace the Merlin card with a more robust design. We therefore recommend to NOT make Merlin support your buying decision for the P96 software package:
- Fixed a MuForce hit in the Merlin card driver.
- Due to bad routing, the clock generator of the Merlin card cannot feed clock rates higher than 80Mhz into the chip, even if this clock is later on divided down in the Tseng chip. Thus, the default setting of the card now disables all settings of the clock generator that generates pixel clocks beyond this limit. If you really want to try higher clock frequencies (on your own risk), set the tool type OVERCLOCK=YES in the monitor icon.
- Due to hardware design issues, the TsengET4000w32 chip may see false data on write requests to its registers, causing hangs or blitting defects on its screen. The new Tseng driver is now extra careful to verify that the correct data has been written for some particularly critical registers, though not for all registers. A particularly critical phase are mode changes, which should be avoided if possible.
- Due to hardware issues, previous Tseng chip drivers may have hung the system while waiting for the completion of a blitter operation. The new driver attempts to work around this problem as much as possible.
- The Merlin and Tseng drivers now disable the display while modifying some of the chip registers. This helps to minimize hardware hangs of the chip, but does not eliminate them completely. Again, this is a hardware design issue, not a driver issue.
- The Merlin card driver no longer indicates to use a more aggressive MMU table mapping; instead, the most conservative setting is now default. Do not attempt to "fix" this mapping as the Tseng chip can map its blitter registers into the VGA memory area, and those hardware registers may not tolerate write reordering as imposed by more aggressive MMU table settings.
- The Merlin card driver did not indicate the maximum mode width for all modes correctly. Due to limited size of its hardware registers, Hi-color modes cannot be wider than 1024 pixels, true-color modes cannot be wider than 684 pixels and true-alpha modes cannot be wider than 512 pixels.
- To limit stability issues, the hardware interrupt of the Merlin card can now be turned off by adding the "INTERRUPT=No" tool type into the Merlin monitor icon.
- The Merlin card no longer provides its own functions to copy planar data from chip memory to VGA card memory as the default version of the rtg.library provides this function already by exactly the same algorithm.
- Due to hardware limitations, the Sprite generated by the Merlin card (actually, the RAM DAC on the card) is limited to 32x32 pixels for high-res sprites, and 16x16 pixels for "big" sprites (i.e. BIGSPRITE=Yes in the monitor driver). Thus, tall pointer images may be clipped at the bottom. There is nothing the driver can do against this limitation.
- The TsengET4000w32 chip offers a memory overlay feature which is now accessible through the P96 "Pip" (Picture-in-Picture) interface. However, as the Tseng chip does not have an intergrated RAM DAC, this memory window is rather limited. The RBGMode (pixel mode, pixel organization) within the memory window MUST be identical to the RGB Mode of the screen, and it cannot be planar. That is, you can only have "chunky" memory windows on "chunky" screens, "hi-color" overlays on "hi-color" screens and "true-color" overlays on "true-color" screens. The memory window neither supports opacity, thus the memory window only appears if it is topmost on the screen and not overlapped or clipped. Otherwise, the driver turns the memory window off. There is a PIP demo program on Aminet including sources. Note that this demo program attempts to create a "hi-color" overlay, which - according to the above restrictions - only operates on a hi-color screen.
- If you see strange defects when rendering text or icons with the Merlin card, try adding SYSTEM2SCREENBLITS=No to the tool types of the Merlin monitor icon. This prevents blitter usage in those cases where the host CPU delivers data manually without a source buffer on the card. Since data transfers to the Merlin card are particularly flakey, this may prevent already some issues.
- If you still see screen corruptions on rendering, you may have to disable the Merlin blitter altogether. For that, add the tooltype NOBLITTER=Yes to the Merlin monitor icon."
(dr)
[News message: 02. Mar. 2022, 05:44] [Comments: 0]
[Send via e-mail] [Print version] [ASCII version]
|
