P96 3.0.0 (and later) news and support

[my_pc_is_amiga]

Thanks -- Thomas. I got it and tried it out. It is working better but do see it go off if I don't have the flickerfixer screen in forefront.

1) WB on CV64 -> Hires Laced on flicker fixer.

If WB is in forefront the flickerfixer gets turned off. When I switch to Hires Laced as the forefront screen, it comes back. This is better but would be nice to keep the flickerfixer on even when it is background screen.

2) If I have a 3rd RTG screen on PIV and put Hires Laced in forefront and do an Amiga-N to go to WB on CV64, then the flickerfixer stays on.

[Thomas Richter]

I'm sorry, but your description is so sketchy that I can hardly make much sense of it. Maybe you put it down to a couple of instructions which programs you open in which screen mode, and how you arrange screens.


Edit: Now that Jens has apparently verified that your license is still active, you can also just send me a mail privately and I'll forward you another test version, that's probably keeping turn-around times a bit smaller.

[my_pc_is_amiga]

Thanks Thomas--will send you a PM. Hopefully, below description will make sense better but I can try to clarify more if needed. I have PAL, NTSC, CV64, and PIV drivers activated in DEVS:monitors/

With these 2 screens only:
a) Workbench on CV64 800x600 screen
b) AdPro on HiRes Laced screen.

If I do an Amiga-N or Amiga-M while on ADPro screen, mouse pointer goes to Workbench screen and then the ADpro screen on PIV flickerfixer output is off (black). If I do an Amiga-M, the mouse pointer goes back to ADPro screen and flickerfixer output is on. Workbench screen on CV64 stays on no matter how I flip screens.

Also, the ADPro screen stays on the Amiga RGB 23-pin output as well when flipping screens. It is just the flickerfixer on PIV that goes off.

[Rotzloeffel]

Driver for Retina Z2 tested and works great. You need an MMU!

[Thomas Richter]

Just minutes ago, the 3.3.0 release of P96 has been published and can now be obtained from iComp.
This is again a major release with comes with one new feature and new drivers.

The 3.3.0 release provides now infrastructure and support for graphics cards that allow mode-mixing to enable screen dragging of screens using different modes. On supported hardware, you can now also drag screens over each other whose modes differ. The following hardware supports this:

For the Picasso IV, one can now drag hi-color screens over chunky screens and vice versa.
For the CVision3D, one can drag almost any screen mode over any other screen mode. As a side effect of the new flexibility, 24-bit color modes can now also be dragged which was not possible before.
UAE supports now dragging of all screen modes, it currently needs to be enabled by a (still hidden) switch.

Two additional graphic cards are now also supported. First, the Retina Z2 is now supported. Since the hardware only provides segmented memory access, a working MMU and the mmu.library is required to get this hardware working.

Second, the Visiona board, based on the INMOS G300 chip is now supported. This card requires either a CRT accepting TV signals, or a LCD monitor and a special adapter cable since it generates somewhat unusual signals. Actually, it creates something closer to a TV signal and not a VGA compatible signal.

The CVision3D now also supports hardware-accelerated planar to chunky conversions.

The CPU based chunky to planar and planar to chunky conversions have been implemented from scratch. Your mileage may vary, though on my 68060 based A2000, the functions are 30% to 100% faster.

The BestModeID function providing a fitting screen mode ID under given requirements has been patched to work also with RTG modes. Unfortunately, the Os function, even as of 3.2.1, has a bug that prevents its proper function with P96.

The P96 guide is reworked, and includes now a FAQ, a list of monitor icon tool types, environment variables and an introduction to P96Mode.

There are also a couple of bug fixes I will report later on.

I will report separately on all these points in follow-up posts in more detail.

[hexaae]

Originally Posted by Thomas Richter

UAE supports now dragging of all screen modes, it currently needs to be enabled by a (still hidden) switch.

That is... ?

[Thomas Richter]

I believe I'd rather leave that to Toni to reveal, but I would assume that Toni will provide an updated version of UAE that enables this feature by default in the future.

[Toni Wilen]

4.9.1 + "-p96test 1" in command line without quotes might do it. Unsupported. It works this way because API wasn't finalized when 4.9.1 was released.

[Leon Besson]

Great News Thomas!

The issue with the graphics breakup on iBrowse came back to haunt me on my Mediator using a Voodoo 4. When I go back to 2.1c this is back to normal.
Will contact Elbox and iBrowse guys to see if there is anything to fix this.
All I will say, is that it only happens when I use the 8MB jumpered mode on the mediator. So can only gather a memory addressing issue?

Anyway I have a Micronik Board and a Picasso IV setup to play with soon, so Version 3.3.0 is very welcomed.

Keep up the good work Mang!

[Thomas Richter]

The P96 driver interface did not change, at least not knowingly. Thus, it is up to Elbox to maintain their products. I can only assume (from the history of their products) that they guessed the interface from reverse engineering and thus did not fully implement the interface. The P96 API is specified in the P96 Wiki, which you find here:

http://wiki.icomp.de/wiki/P96

[hexaae]

Originally Posted by Toni Wilen

4.9.1 + "-p96test 1" in command line without quotes might do it. Unsupported. It works this way because API wasn't finalized when 4.9.1 was released.

Thank you!
Works great (WB 32bit, PPaint 5bit):

There's just a minor glitch due to mouse pointer (I use PVS with Softsprite=YES) changing shape/res/depth (see the PPaint titlebar before the ©Cloanto mark), and pointer disappears on PPaint screen portion, but it's acceptable ATM

[Swe_Kryten2x4b]

Originally Posted by hexaae

There's just a minor glitch due to mouse pointer (I use PVS with Softsprite=YES) changing shape/res/depth (see the PPaint titlebar before the ©Cloanto mark), and pointer disappears on PPaint screen portion, but it's acceptable ATM

Speaking of PVS...is there a way to make that tool work with drivers that are not included in the P96 archive? In my case, the vampire board. All I get is a "No Picasso96 monitor files located". Or should I bring it up with the apollo-devs? I guess the same applies for having draggable screens with the vampire?

No other issues with either the driver itself or P96 that I've noticed so great work!

[hexaae]

Can't help with Vampire board sorry You should ask iComp and/or Vampire team...

Here are a few glitches testing the new screen dragging feature:
[ Show youtube player ]

[my_pc_is_amiga]

I'm installing 3.3.0 and Installer is saying I have 1.683 of Picasso96Mode and it wants to install 1.664. Maybe I'm not reading the revision correctly but is 1.664 actually an older one?

[Thomas Richter]

The UAE driver is maintained by Toni, not myself, so please check there. The same goes to the Elbox hardware and the vampire hardware, please ask there for updates. I neither have their hardware, nor their driver sources, nor documentation. It is really about over time that Gunnar and frieds finally get screen dragging working because the hardware can do it.

[Thomas Richter]

Maybe a couple of comments on the new drivers. The Retina Z2 is an older card that was up to now unsupported because it only supports "segmented memory". This is a legacy of the PC architecture and its "640K is enough for everyone", which means that there is only a 128K window for the graphics memory.

Chips got around that by bank switching, such that there was actually more memory available on the card (up to 4MB on the Retina) and with bank switching registers, only a window of the memory was mapped into the VGA region.

The Retina Z2 has in total an expansion size of 128K, but 64K are occupied by the I/O registers (actually, only about 20 bytes of the 64K region - wasteful!), and the VGA memory window is 64K in size only. This is barely sufficient for 800x600 in 16 colors (planar) or 320x200 in 8-bit chunky, so it is not useful. It needs some help from the MMU.

So what the driver does is that it allocates a continuous region of 4MB address space which becomes the frame buffer of the card. Whenever an access is made there, the region around the access is mapped to the VGA memory window of the card by means of the MMU, while updating the bank-switching registers of the card such that they fit to the region the CPU accessed.

Then, when the CPU wants to access something outside of the region, the process is repeated: The card bank switching registers are reconfigured, and the MMU is reconfigured - through the exception handler mechanism of the mmu.library.

An interestng problem is that of "block copy" or "blitting" because the card has no blitter either - everything is done by the CPU. On a block move, instructions like

move.l (a0)+,(a1)+

want to copy large VGA memory regions. It seems that this requires two exception per instruction if the source and the destination are not within the same "window region" of the VGA chip.

Luckely, the situation is not quite as bad as the chip has two sets of bank switching registers, each responsible for 32K of the 64K window in total, and the exception handler is smart enough to use them alternatively, such that one bank switching register is used for the source, and another one is used for the target.

Actually, the speed is not that bad - the exceptions do not matter too much - but it shows that the card has no bitter and the CPU has to do all the footwork.

Other than that, the Retina is quite ok. It does have a sprite which works up to hi-color, supports screen-dragging, has a working hardware interrupt for screen synchronization and is quite tolerable for overclocking. Actually, the 2MB version accepts higher frequencies than the 4MB version in my experiments.

[Thomas Richter]

The Visiona is, however, quite special because its chipset is not the usual "PC style VGA chip". It's an INMOS G300C, which is part of a "transputer chipset" and was as such created for high priced transputer workstations. As such, it has a (for its time) very high pixel clock of 110Mhz suitable for 1280x1024 in chunky, quite powerful for its age.

However, this chipset is really special. First of all, it does not generate a VGA compatible signal. Thus, you cannot get away with a VGA monitor, or a LCD/TFT monitor. Problem is that it stops generating HSYNC in the VSYNC region, and the average VGA monitor does not take this signal. For the same reason, sync polarity cannot be configured through P96Mode as it usually can as polarity is fixed. Rather, the card comes with 4 sync modes, all configured through the tool type of the monitor icon.

SYNC=Separate is composite sync with separate h and v sync signals. Unfortunately, this is in most cases *not* what you want because it is not a VGA compatible sync. Instead, you want

SYNC=Tesselated which is a composite sync variant with a particular pattern on top of the hsync which some older TFT/LCD monitors still accept. However, you need to cut the vsync line of the cable, which still carries an (incomplete) vsync signal.

SYNC=Composite is a composite sync, but without the pattern ("tesselation") on the hsync signal. Typically not useful.

SYNC=Green modulates the sync signal on the green output. This is what high-priced MAC monitors used to expect. You connected them by 3 BNC cables, one for red, green and blue each. The green one also carries syncing signals. Some older TFTs also accept this over VGA.

Thus, please don't expect that you can just connect your average TFT to the Visiona and get a picture. It's quite complicated for the INMOS chips.

[Thomas Richter]

Also, in other aspects the Visiona/INMOS is special. Its design is based on VRAM, dual-ported video RAM to which the CPU has one (random) access, though the INMOS accesses through a "shift register". A single signal loads one row of the RAMs into a 512 byte long shift register on the RAM chips, and then clocks the signal out at 1/4 of the pixel clock. There are four such VRAM banks in parallel, each clocked at 27MHz, giving in total the 110MHz pixel clock.

This is part of the "transputer design", namely to offload parts of the logic to the RAM, which takes over the job of the "sequencer" in regular VGA chips.

Unfortunately, it also means that everything needs to be configured manually by the driver. The RAMs need a particular time to load their rows into the shift register, and this prefetch needs to be complete before the picture starts. The shift register also needs to be reloaded before it runs dry, which can happen in the middle of the screen, so the logic for re-filling it needs to be configured, too.

Since the shift register operates continuously, there is no separate "pitch" for the lines, the RAM addresses just wrap around at the right end of the screen to the next line. This excludes panning. Well, one could pan for screens whose width is just about the width of the shift register, and then reload the shift registers earlier. That is, horizontal panning could work for screen width < 2048 pixels in chunky, or 512 pixels for true-color, which is not very useful. Panning also requires the display to be turned off for a short time.

Speaking about addresses, for the CPU row and column addresses of the VRAM are swapped, which has the consequence that the bits of addresses need to be "swapped" before they can be loaded into the chip as the chip sees rows and columns of the video RAM in reverse order compared to the chip. This requires that each frame buffer has to start at a multiple of 2K. This type of alignment is taken care of by the INMOS driver.

There is more swapping needed - the INMOS chip also swaps out the least significant bit of a byte first, such that it appears leftmost on the screen. The Amiga chipset and thus all of graphics and intuition expects that the most significant bit appears leftmost. The designers of the Visiona card got around that by reversing the bits that go to the VRAM from the Zorro port, but it also means that the chip sees palette entries "the wrong way around". A byte $01 written into the VRAM will appear as $80 to the chip (as bits are shuffed between zorro and RAM) and thus palette entry $80 needs to be populated to define the color for pixel value $01. A similar "twist" appears for true-color where, fortunately, palette registers also apply.

While the chip reaches an (for its time outstanding) pixel clock of 110Mhz, it requires four parallel accesses for true-color, which means that the air gets relatively thin for true-color. While 1280x1024 works in chunky, 800x600 in true-color is out of reach without overclocking. Note that a 800x600 true-color screen requires 3200x600 bytes, and that's too much for the poor chip.

It neither has a blitter, nor a software sprite, so things are rather slow....

There are more glitches the chip has: Typically, one gets around pixel speed limitations by interlacing the signal, but unfortunately, the strange "shift register VRAM" design has its limits here: As shift registers are continuously re-loaded with the next address when running dry, they cannot just leave out every other line to form one field of an interlaced frame. One can increment the shift register address by 2 instead of 1 for interlace, but this happens every time the shift register runs dry, and not every screen line. Thus, interlaced would be only possible for screens whose lines are either an entire amount of shift registers wide (2048 bytes) or below this number of lines wide (<2048 pixels in chunky, or 512 in true-color). Which means that interlace would be only available if you do not need it anyhow because the screen is still small.

Hence, no interlace support either at this point.

Then, the chip also reacts allergic if you change the palette on the screen. If you do, there is a potential conflict between the chip attempting to access a palette entry for generating screen content, and the CPU attempting to write into the same register. While the chip specs says that the chip prevents this problem from happening by repeating the last pixel, in reality the screen just flickers badly whenever you adjust colors.

So in net effect, the Visiona is an interesting piece of hardware that came out of a transputer company, it is not a very practical or powerful card in reality. It is very picky in which monitors it can drive, and besides its relatively high pixel clock for chunky, it cannot do much. No sprite, no blittter, no interlace, no scan-doubling, no panning, and true-color only at low resolutions.

[hexaae]

UNSTABLE
P96 3.3.0 I've found is unusable here: have no idea why, but coming from P963.2.3 and replacing old libs with new ones (copy RamDisk:Picasso96Install/Libs/#? LIBS: ALL) works only on the very first reboot.
The strange thing is that on 2nd reboot or more (even if quit and relaunch WinUAE!) UAEgfx monitor driver crashes while booting every single time ("Illegal instruction" guru, didn't help switching to 060-->040... I use MMULib), even if I remove the hidden option "-p96test 1". Have had to roll-back to 3.2.3 (copy RamDisk:Picasso96Install/Libs/#? LIBS: ALL).

(Started a thread on iCOMP forum...)

Maybe a simple manual install "copy RamDisk:Picasso96Install/Libs/#? LIBS: ALL" is not enough anymore after 3.3.0?

[Thomas Richter]

Talk to Toni please. I'm not maintaining the UAE driver.