P96 3.0.0 (and later) news and support

[AC/DC HACKER!]

I appreciate your attempt help get on the same page.

Originally Posted by Thomas Richter

Sorry, I may be stupid, but I do not understand. P-IV does have a scandoubler, and it is active whenever a native mode is shown. It takes its input, coming from the native Amiga output, and provides a (rescaned, digitized) version of it at the output of the P-IV. This is the pass-through.

I don't consider you stupid at all or anyone else that matter. That's an extremely insulting statement that people make. Everyone can learn.


I know it has a Scandoubler, I've been using it for over 30 years. I realize some connections are being made so I'll expand even further. I thought that commenting about the Picasso 4 monitor and the CVisionPPC monitor being used together or not was enough to get the message across. Seems not. So I'll explain my setup further.


The Picasso 4 is connected to my HDTV via a VGA+Audio-to-HDMI connector. So Audio of Picasso 4 is connecting to VGA-to-HDMI connector. Functions very well that way. Display of Amiga video and Picasso 640x480 or high screens do great.


My CVisionPPC is connected to another, order monitor.

You can select via a tool type of the monitor driver whether a particular board has a monitor switch and is in the display chain. I forgot the name of the tool type, but it is in the guide/manual.

You mean SwitchType=JAV0SOFT or "JAVOSOFT" doesn't seem to do anything. I also tried using SwitchType=PicassoIV but that didn't help. CVisionPPC's screen just goes blank and then I hear garbled sounds form whatever WHDLoad game.

If you want a mode-promotion utility to render native screens instead on the P-IV without the "scan doubler" (as said, this is not really a scan doubler, but it serves its purpose), there are plenty on Aminet.

Noo....I don't want to use ModePro for any other Mode Promotion program. That was my point. I would rather Not use any of those. I have used ModePro in the past and it's great, I know how to use it. But I have it disabled because don't want to.

P-IV does not have a "pass-through" in the classical sense (i.e. it does not have a switch that would simply bypass the signal from the VGA-in to the VGA-out), it has a frame grabber and digitizer sitting at the input. I'm not sure whether that answers the question. Whether WHDLoad uses that correctly I doubt. There is no direct interface for that. To activate the "bypass", you simply need to open a native screen via the operating system.

I understand it doesn't have a Hardware Switch that you flip on the board. Which is why I commented about CGX4 have software switches in ToolTypes and ENVARC:/ENV: that may be set. Shall I show you pictures?

I'm not clear what you are observing, but I wouldn't be surprised if the P-IV screen grabber only takes 15Khz input as it needs to know the frequency of the incoming signal. It is probably not able to digitize any 31kHz mode, but I may be wrong. The simplest solution would be to have the P-IV input directly connected to the native chipset output, and route the output of the P-IV.

15Khz or 31Khz has functioned very well here with Picasso96 2.0 and the newer versions. Before CVisionPPC driver was added. That's why I typed that if I don't have the CVisionPPC monitor IN monitors and ONLY the PicassoIV monitor in monitors then the PicassoIV board displays Amiga Native modes as it should. I'm not sure how much clearer I may be but I will keep attempting if confusion still exists.

The CVisionPPC does not have a monitor pass-through at all.

I understand that completely. What the CVisionPPC will do...before the monitor is loaded and initialized is display a 640x480 native Amiga screen. So will the PicassoIV...before the monitor driver is loaded. I could share screen shots if that's helpful.

You need an external switch for it. There is a tool type to enable one, but I do not know the brand and where you could get it.

That's a clue I didn't understand before. So, as I typed above, I tried "PicassoIV" to see if it would force native screens to go to the monitor, but that didn't see to work. So, I don't know what "brand" I'm looking for. Device ID? As in what "WhichAmiga" shows for the board? I'll try that.

If you need a CVIsionPPC and a P-IV in the same system at once, the only option is to have two monitors. Note, however, that such a setup would *not* be able to show native screens. The CVisionPPC driver *has* to promote all native modes to the CVisionPPC, unfortunately. This is simply because the firmware of the card already installs patches into the operating system, and the original entry points into the ROM required to create a native chipset screen are already lost at the time P96 jumps in.

Then I guess my description above that paragraph will be a surprise to you. I don't "need" the CVisionPPC and Picasso 4 boards installed at the same time but I am not going to disconnect and reconnect often to use one or the other. I can see that for now "disabling" CVisionPPC from monitors is what is working. So the physical boards stay attached. They function very well with GFX4 as I'm hoping P96 will do some time.



Tecnically, this is not a patch of a library entry point, but it is the "VecTable" in the display info data base for all native screen modes that are patched over by the CVisionPPC. Unfortunately, P96 cannot know where these entries should go into the ROM, the ROM vectors for them are not available anywhere, and thus, any attempt to create a native display on the CVisionPPC will fail. P5 called that a "software scandoubler", but it is actually a ROM-based mode promotion.[/QUOTE]




I'm not attempting to create a native display for the CVisionPPC with the CVisionPPC Monitor loaded, not at all. I'm attempt to get WHDLoad Screens to show on PicassoIV board when the PicassoIV monitor is also loaded and running with CVisionPPC monitor loaded and running. Currently CGX4 does this, P96 does not...not that I have...found, yet.


I hope this clarifies better.

[AC/DC HACKER!]

Originally Posted by Jope

So is this the DISPLAYCHAIN=Yes tooltype?

And this must be yes in the monitor icon of the board that has the native mode pass through hardware and no in the icons of the boards that do not have the pass through?

That's exactly what I'm used to and thought.


For PicassoIV I have DISPLAYCHAIN=Yes
For CVisionPPC I have DISPLAYCHAIN=No


Here's the display of my PicassoIV board from these settings.

[zipper]

Originally Posted by AC/DC HACKER!

Then I guess my description above that paragraph will be a surprise to you. I don't "need" the CVisionPPC and Picasso 4 boards installed at the same time but I am not going to disconnect and reconnect often to use one or the other. I can see that for now "disabling" CVisionPPC from monitors is what is working. So the physical boards stay attached. They function very well with GFX4 as I'm hoping P96 will do some time.

I remember unused CVPPC (Driver moved) caused noticeable slowdown to my Voodoo3 on Prometheus when doing benchmarks so I then removed CVPPC.

[AC/DC HACKER!]

Zippper:

The CVPPC does slow the use of CSPPC some, but it doesn't slow the Picasso 4 at all. I haven't had any conflicts between Picasso 4 and CVisionPPC with CGX4. I don't rely on benchmarks, more about noticing.

[SnkBitten]

Originally Posted by pcotter

Hello
Can someone confirm if tools like ModePro is working?
Doesn't work for me. Have only tried on the Amithlon.
Thanks

It's working for me on my Amithlon system. At first it wasn't with the previously set apps/screenmodes. But I removed them and set them up again and they were promoted. Tested with Sysinfo since that screen needs the 'Planar' option set to keep it from looking like garbage.

Not looking forward to resetting all the Lightwave screenmode promotions up again. *Edit* Didn't need too, those still worked. Weird that I had to delete the one for sysinfo and re-add it to ModePro.

I tested on my Virtualbox Amithlon and it worked so I installed the new P96 on my physical Amithlon and it didn't.....so I "guessed" at deleting the configured apps/screens and adding them back....and it worked.

[Jope]

Originally Posted by Thomas Richter

Err... it must go to the monitor type of the board that is not in the display chain. The display chain is the chain of switches and graphics cards that route the video signal from the amiga RGB output, over one or multiple graphics cards, to the monitor input.


If a board is not in the display chain, then P96 does not attempt to switch its VGA switch *off* if the currently active screen(s) are on another board. Note that this is only a control of the VGA switch (if the board has one). If the board has no VGA switch, well, then there is nothing to be switched, and the output of the board is always active. That is what happens for the CVisionPPC.

Thanks, now I understand the idea of the display chain. I was needlessly limiting my thinking to a single RTG board + Amiga native output scenario.

I had to go and double check whether I had missed something in the documentation, but basically this concept is not covered in there apart from a very quick mention when discussing this particular tooltype. I wonder what else I've misunderstood about P96 over the years. ;-)

[Jope]

Originally Posted by Thomas Richter

The CVisionPPC does not have a monitor pass-through at all. You need an external switch for it. There is a tool type to enable one, but I do not know the brand and where you could get it.

So this is the SwitchType=JAVOSOFT option. The documentation mentions, that this is only for CVPPC..

I found this, does this describe the JAVOSOFT device?
https://forum.amiga.org/index.php?to...3703#msg173703

I proposed on the Picasso96 ML to use the Sel DF3 signal, by creating the
proper function inside the RTG software, to control an external switcher.
They answered me (Tobias, a P96 developer) that both CyberGFX and P96 have
such a function but realized in a more clever way: a sync signal (V or H) is
set to a costant voltage level when an Amiga native screen becomes frontmost.

But this system is depending on the chipset used by the board: normally all
those support DPMS are able to set the sync signals this way.

Wouldn't it be great to support this on all possible chips + also release the specification on which sync(s) need to be held (up or down)?

This sounds like an ideal solution compared to the Ratte switch, which takes a line from the parallel port.

What am I missing? Is it not possible to implement for others than CVPPC?

[Thomas Richter]

Originally Posted by Jope

So this is the SwitchType=JAVOSOFT option. The documentation mentions, that this is only for CVPPC..

I found this, does this describe the JAVOSOFT device?
https://forum.amiga.org/index.php?to...3703#msg173703

Maybe. The software adaption in the CVisionPPC does not actually provide details. It rather expects that the firmware of the switcher device deposits a call-back hook in the boardInfo->CardData[14] array, through which the external switcher controlled. How exactly it does that is then up to the firmware. Whether the firmware of the above device does exactly that I do not know.

Originally Posted by Jope

Wouldn't it be great to support this on all possible chips + also release the specification on which sync(s) need to be held (up or down)?

The first question is "no", because VGA switching is not chip-dependent, but card-dependent, and of the cards I know, all but the CVisionPPC do have a VGA switch (of some form). Second, how exactly switching is made is not part of the interface. It is a fairly generic hook system that can use a variety of methods to drive an external switch.

Originally Posted by Jope

What am I missing? Is it not possible to implement for others than CVPPC?

Why? All the other cards(!) populate the boardinfo hook to switch the signal. Is there a particular reason why you do not want to use the on-board switch of the existing VGA cards?

[Thomas Richter]

Originally Posted by AC/DC HACKER!

The Picasso 4 is connected to my HDTV via a VGA+Audio-to-HDMI connector. So Audio of Picasso 4 is connecting to VGA-to-HDMI connector. Functions very well that way. Display of Amiga video and Picasso 640x480 or high screens do great.


My CVisionPPC is connected to another, order monitor.

Yes, that is certainly a recommended setup, though it still means that any attempt to open a native screen will cause a screen to open on the CVisionPPC. This is unavoidable. As stated, the CVisionPPC firmware installs already at boot-time patches (well, not exactly that, but close enough) that replace the functions that build a native display. So any attempt to get a native screen through the operating system must fail.


All P96 can do is to overwrite these functions with its own, so the "CVisionPPC software scandoubler" aka "firmware driven mode promotion" continues to work. It cannot remove these patches as the original entry points have been lost.


In short: Once you have a CVisionPPC in your system, the native Amiga video output is dead and cannot be reached from the operating system.

Originally Posted by AC/DC HACKER!

You mean SwitchType=JAV0SOFT or "JAVOSOFT" doesn't seem to do anything. I also tried using SwitchType=PicassoIV but that didn't help. CVisionPPC's screen just goes blank and then I hear garbled sounds form whatever WHDLoad game.

Which is not surprising because there is still the mode promotion for the CVisionPPC active. Again, see above: CVisionPPC in the system, no native video.

Originally Posted by AC/DC HACKER!

Noo....I don't want to use ModePro for any other Mode Promotion program.

That's too bad, but P5 decided that you get one once booting with the CVisionPPC in the system.

Originally Posted by AC/DC HACKER!

I understand it doesn't have a Hardware Switch that you flip on the board. Which is why I commented about CGX4 have software switches in ToolTypes and ENVARC:/ENV: that may be set. Shall I show you pictures?

That wouldn't help me because it would still not document how to get rid of the P5 firmware patches to the system. That is undocumented, vendor-specific territory. P5 tended *not* to document what they did, and any attempt to get information from them ended in a disaster. I tried that in the past, and it didn't work. I don't want to go through the painful exercise once more.

Originally Posted by AC/DC HACKER!

I'm not attempting to create a native display for the CVisionPPC with the CVisionPPC Monitor loaded, not at all. I'm attempt to get WHDLoad Screens to show on PicassoIV board when the PicassoIV monitor is also loaded and running with CVisionPPC monitor loaded and running. Currently CGX4 does this, P96 does not...not that I have...found, yet.


I hope this clarifies better.

No, I afraid not. If WHDLoad uses the operating system to open a screen, then that screen will open on whatever graphics card WHDLoad tells the Os to open on. Let it be a CVisionPPC screen or a PIV-screen. That surely works. If it attempts to open a native screen, that will *forcefully* end up as a CVisionPPC screen, without any chane of having that fixed. If it decides to poke the custom chips, well... I'm out of the game.

[AC/DC HACKER!]

Originally Posted by Thomas Richter

Yes, that is certainly a recommended setup, though it still means that any attempt to open a native screen will cause a screen to open on the CVisionPPC. This is unavoidable. As stated, the CVisionPPC firmware installs already at boot-time patches (well, not exactly that, but close enough) that replace the functions that build a native display. So any attempt to get a native screen through the operating system must fail.

Okay, that makes sense to me. It's what I was also figuring. Interesting that if I disable CVPPC Monitor, the Picasso 4 will change display and show native Amiga screen. Even if the CVPPC board is connected to CSPPC. Hmm..

All P96 can do is to overwrite these functions with its own, so the "CVisionPPC software scandoubler" aka "firmware driven mode promotion" continues to work. It cannot remove these patches as the original entry points have been lost.

Ahhhh, that's what I was getting at. So this is what CyberGFX 4 is doing. They found a way to override CVPPC Firmware. Which point to info that you commented on before, they got info fro Phase 5 to do it. Nice...for them, nasty for others like yourself..and us. Haha!

In short: Once you have a CVisionPPC in your system, the native Amiga video output is dead and cannot be reached from the operating system.

I'm getting this about the OS...now. It's only reachable by the Hardware, Picasso 4/CVisionPPC and Driver software Picasso96/P96 and CGX 4. So, if I connected to my literal Amiga Video out port, which I don't have a connector for..it would display but not any game or other programs screens.

Which is not surprising because there is still the mode promotion for the CVisionPPC active. Again, see above: CVisionPPC in the system, no native video.

That's too bad, but P5 decided that you get one once booting with the CVisionPPC in the system.

Since the mode promotion in CVisionPPC is still active, that's why if I have Workbench displayed on CVPPC and run a WHDLoad game, it then shows on Picasso 4 digitized screen...not always "correct" video, some off center happening with some games, but very much playable.


When I boot the A4000..I get displays from both PicassoIV and CVisionPPC of Boot menu, and my custom menu before anything else loads, including SetPatch. So both are displaying native Amiga screen during boot. So, both are digitizing it. Hmm.. Years later, interesting what you learn. Always learning. Fantastic.

That wouldn't help me because it would still not document how to get rid of the P5 firmware patches to the system. That is undocumented, vendor-specific territory. P5 tended *not* to document what they did, and any attempt to get information from them ended in a disaster. I tried that in the past, and it didn't work. I don't want to go through the painful exercise once more.

Here's the part I commented about. Cool for P5 & CGX..but not for us and You now. I've read about your attempts, I very much understand.

No, I afraid not. If WHDLoad uses the operating system to open a screen, then that screen will open on whatever graphics card WHDLoad tells the Os to open on. Let it be a CVisionPPC screen or a PIV-screen. That surely works. If it attempts to open a native screen, that will *forcefully* end up as a CVisionPPC screen, without any chane of having that fixed. If it decides to poke the custom chips, well... I'm out of the game.

If I have Workbench on PIV screen, WHDLoad ATTEMPTS and fails to display on CVPPC, and sound is very odd. If I have Workbench on CVPPC, then WHDLoad displays on PIV..and everything is functioning as it should.


You've helped clarify well. I knew we'd get there. Hehe. It's an easy enough workaround for now. Either display CVPPC monitor OR display Workbench on CVPPC. Not hard to do. Just didn't expected to have to do that. It's worth it for new Intuition.

[RDP]

Just wanted to report that screen dragging works for me, but I see occiasionally flashes of the screen underneather the screen that is being dragged as I move the screen up and down. Not sure if this is P96 related, or related to my system:

3000D
3.1.4 & ROMS
Cybervision 64

I'm using a 800x600 16bit screen. To get my second screen I just open DOPUS5. The recommendation to have Multiview open a separate screen never seemed to work for me, I could not drag it. I assume it somehow is not a copy of the properties of my WB screen, therefore incompatible for dragging.


thanks all,
RDP

[asymetrix]

@thread

excellent discussion.
I wonder if getting early enough (structures that log data) - to log changes would help.
Even if that means adding new features that store or reset data or even copy structures / settings into dummys.
Abstract it away. You want access, request it.
Detect specific software and deal with them at each stage.

We could do with better documentation, so one can visualize it better.

[Thomas Richter]

Originally Posted by RDP

Just wanted to report that screen dragging works for me, but I see occiasionally flashes of the screen underneather the screen that is being dragged as I move the screen up and down. Not sure if this is P96 related, or related to my system.

It is related to the legacy VGA system screen dragging is based on. Screen dragging depends on a VGA feature called "line compare register". Unfortunately, this is not a single register, but the bits are spread out over three registers. Even worse, it is not that you just write a byte to a register, but due to the intel 8080 limitation of at most 256 IO registers (yes, really) for which all this mess was developed, you have first to write a byte into a "port register" that tells you which feature is to address, and then write the register value into a second "data register" which is then redirected into the right internal chipset register.

Thus, in the end, one adjustment, six bytes to write. Now, the problem is that it can happen that one of the three bytes is updated, whereas the other two are not, and thus the screen split happens at the wrong position on the screen as the chipset then reads a partially updated register value.

P96 tries to address that by waiting to a vertical blank before updating the registers, but due to the Amiga being multitasking, this is not entirely reliable as another task can jump in just after we have waited, and then the timing is off. Even more unfortunate, not every graphics card can trigger a vertical retrace interrupt within which we could update the registers.

Thus, it is really the combination of multiple shortcomings of the VGA and 8080 legacy that causes this.

[Thomas Richter]

Originally Posted by asymetrix

@thread

excellent discussion.
I wonder if getting early enough (structures that log data) - to log changes would help.

There is a History.readme file in the distribution which lists the changes.

[asymetrix]

Originally Posted by Thomas Richter

There is a History.readme file in the distribution which lists the changes.

I meant when software patches the system, the operating system logs those changes at runtime, so one could undo it.



[offtopic]

I watched a Linux talk where they proposed a Javascript like layer in the kernel to update components in realtime.


Alot of Linux devs are getting burned out with the constant maintanance, so they want a more automated and clean system.

eBPF - Rethinking the Linux Kernel:


[ Show youtube player ]

[Thomas Richter]

Originally Posted by asymetrix

I meant when software patches the system, the operating system logs those changes at runtime, so one could undo it.

You typically do not want to undo selected patches since you do not know how they relate to each other.



To view the installed patches:


http://aminet.net/dev/debug/TRSaferPtch.lha



All this exists.

Originally Posted by asymetrix

I watched a Linux talk where they proposed a Javascript like layer in the kernel to update components in realtime.


Alot of Linux devs are getting burned out with the constant maintanance, so they want a more automated and clean system.

I don't think a javascript system would lead to a cleaner system. It would lead to an even more convoluted system that is even harder to maintain. More security holes to fix in the patch system. Some of the recent ideas like systemd or pulseaudio were just terrible.

[Thomas Richter]

Originally Posted by nogginthenog

I got dragging partly working.
Made a fresh WB 3.1.4 install with just 060 libs and Pic96. Screen dragging works but only if I select a 32bit screen mode!.

Concerning this, I believe I have now a solution. This is all unnecessary complicated as the S3ViRGE chip on the CVision3D has two options for generating a picture, the classical VGA system (supporting screen dragging) and a "stream processor engine" which adds support for video overlays, but does not support screen dragging. The P96 driver currently uses the second engine, allowing video overlays, but with the side effect that screen dragging does not work.


It does work for 32bit because there the bandwidth is not sufficient to allow video overlays in first place, so the stream processor is turned off.


What is currently happening is that, with immense help of Harald, I am looking into a driver that switches between the two modes of the S3 chip, thus turns off the video overlay once you start dragging. Thus, you would get screen dragging and video overlays, but the latter only if nothing is dragged (fair enough).



You will loose the 24bit RGB mode, but the 32bit mode is still there. This is because the 24-bit mode is only created by the stream processor, and the VGA engine cannot generate it. So the S3 is more like "two chips in one".


Depending on how much patience Harald has, we *may* also get byte/word flipped modes such as ARGB (instead of BGRA) and 15 bit RGB (non-PC) which may be interesting for some emulators. Unfortunately, it is really tough to debug all this without a board at my hands, but at least we know now that in principle my idea is working (i.e. switch between the two video engines the S3 has).

[nogginthenog]

Originally Posted by Thomas Richter

Concerning this, I believe I have now a solution. This is all unnecessary complicated as the S3ViRGE chip on the CVision3D has two options for generating a picture, the classical VGA system (supporting screen dragging) and a "stream processor engine" which adds support for video overlays, but does not support screen dragging. The P96 driver currently uses the second engine, allowing video overlays, but with the side effect that screen dragging does not work.


It does work for 32bit because there the bandwidth is not sufficient to allow video overlays in first place, so the stream processor is turned off.


What is currently happening is that, with immense help of Harald, I am looking into a driver that switches between the two modes of the S3 chip, thus turns off the video overlay once you start dragging. Thus, you would get screen dragging and video overlays, but the latter only if nothing is dragged (fair enough).



You will loose the 24bit RGB mode, but the 32bit mode is still there. This is because the 24-bit mode is only created by the stream processor, and the VGA engine cannot generate it. So the S3 is more like "two chips in one".


Depending on how much patience Harald has, we *may* also get byte/word flipped modes such as ARGB (instead of BGRA) and 15 bit RGB (non-PC) which may be interesting for some emulators. Unfortunately, it is really tough to debug all this without a board at my hands, but at least we know now that in principle my idea is working (i.e. switch between the two video engines the S3 has).

Thanks Thomas. If you need any help testing this please let me know.

[Rotzloeffel]

Originally Posted by Thomas Richter

Depending on how much patience Harald has, we *may* also get byte/word flipped modes such as ARGB (instead of BGRA) and 15 bit RGB (non-PC) which may be interesting for some emulators. Unfortunately, it is really tough to debug all this without a board at my hands, but at least we know now that in principle my idea is working (i.e. switch between the two video engines the S3 has).

Hi Thomas, as you know, I have a lot of patience on this issue The thing is, as you know all very well, that in the real life, there are some boring, stupid, an wierd things going on.... stupid things like a Job, wiered things like a girl friend Children.....(I have 2 sons ) other things to do, but, as far as I can say, the issue reported with the Cybervision 64/3D are on a good way to be fixed!


Dragging is actually working in all depth 8 16 and 32 bit modes, oversized screens scroll very smoothly and an issue with the Mousepointer is also fixed actually. Now we are working on this videoOverlay-thing (what is it good for on CV 64/3D?) but we will do the job, be sure


Regards
Harald

[nogginthenog]

This sounds good Harald!