Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| en:expansion:av:picasso_iv [2015/10/06 19:00] – Tobias Seiler | en:expansion:av:picasso_iv [2024/09/22 00:28] (current) – external edit 127.0.0.1 | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | <awbox translate> | ||
| - | |||
| ====== Picasso IV ====== | ====== Picasso IV ====== | ||
| Line 19: | Line 17: | ||
| As the successor of the [[de: | As the successor of the [[de: | ||
| - | It has a scan doubler and [[wp>Flicker_fixer]] built-in . That means that the Amigas own video signal will be captured by the Picasso IV and changed in a way that it can be displayed on a standard VGA CRT or LCD display. | + | It has a scan doubler and [[wp>Flicker fixer]] built-in . That means that the Amigas own video signal will be captured by the Picasso IV and changed in a way that it can be displayed on a standard VGA CRT or LCD display. |
| - | Expansion | + | Expansions |
| - | But the Picasso IV made a difference in how this was done. | + | But the Picasso IV made a difference in how it was done. |
| - | Conventional flicker fixers temporarily save the picture data of the Amiga line by line in an fast video memory and read them again at double the speed to increase the display frequency of the picture. | + | Conventional flicker fixers temporarily save the picture data of the Amiga line by line in a fast video memory and read them again at double the speed to increase the display frequency of the picture. |
| The Picasso IV uses its graphics controller. This controller has the ability to capture digital video streams into its frame buffer memory. The Picasso IVs flicker fixer is just generating the needed control signals for the graphic controller capture port which is writing the picture data directly into the frame buffer memory to directly output them on the VGA port. | The Picasso IV uses its graphics controller. This controller has the ability to capture digital video streams into its frame buffer memory. The Picasso IVs flicker fixer is just generating the needed control signals for the graphic controller capture port which is writing the picture data directly into the frame buffer memory to directly output them on the VGA port. | ||
| Line 29: | Line 27: | ||
| This just happen at the programmed display rate as with every other screen mode which the card can handle. | This just happen at the programmed display rate as with every other screen mode which the card can handle. | ||
| Unfortunately its not possible to synchronize the output display rate and the input rate. | Unfortunately its not possible to synchronize the output display rate and the input rate. | ||
| - | For that it might happen you see some screen tearing with moving pictures (( [[wpen>Screen_tearing]] )). | + | For that it might happen you see some screen tearing with moving pictures (( [[wp>Screen tearing]] )). |
| - | The flicker | + | The flicker |
| The PicassoIV has several expansion connectors for which some modules have been developed. | The PicassoIV has several expansion connectors for which some modules have been developed. | ||
| Line 40: | Line 38: | ||
| The cards manual also mentions a 3D, an MPEG and a PowerPC processor modul. Those where not built/ | The cards manual also mentions a 3D, an MPEG and a PowerPC processor modul. Those where not built/ | ||
| - | [{{ : | + | [{{ : |
| - | The 3D module was planned to have a Voodoo Graphics | + | The 3D module was planned to have a Voodoo Graphics (( [[wp> |
| To have a better idea of peoples interest in purchasing such a card a poll was started online on Village Tronics website. 500 people declared their interest and the cards layout was done by an external developer. | To have a better idea of peoples interest in purchasing such a card a poll was started online on Village Tronics website. 500 people declared their interest and the cards layout was done by an external developer. | ||
| At the same time the Macintosh market was getting more difficult to handle and new products in this field drew time and money onto them. | At the same time the Macintosh market was getting more difficult to handle and new products in this field drew time and money onto them. | ||
| - | Then Amiga main developer Klaus Burkert left the company, like many others at this point. He bought out all of the companies Amiga hard and software and the associated intelectual property. | + | Then Amiga main developer |
| Soon he started to work at [[wpde> | Soon he started to work at [[wpde> | ||
| Line 102: | Line 100: | ||
| cutable area for use in machines without inline VideoSlot (z.B. B2000) | cutable area for use in machines without inline VideoSlot (z.B. B2000) | ||
| - | ===== hardware compatibility | + | ===== Hardware Compatibility |
| ^ working \\ in^A500^A600^A1000^A1200^A2000^A3000(T)^A4000(T)^CDTV^CD32^ | ^ working \\ in^A500^A600^A1000^A1200^A2000^A3000(T)^A4000(T)^CDTV^CD32^ | ||
| Line 112: | Line 110: | ||
| \\ | \\ | ||
| **Software: | **Software: | ||
| - | **additional requirements: | + | **additional requirements: |
| **note:** Linux/ | **note:** Linux/ | ||
| **known problems:** --\\ | **known problems:** --\\ | ||
| Line 152: | Line 150: | ||
| |2 |First workaround for the Fusion40 (ignore function codes for Z2) (also for some Hardital boards), which is violating the A2000 CPU-Slot specs, it doesn' | |2 |First workaround for the Fusion40 (ignore function codes for Z2) (also for some Hardital boards), which is violating the A2000 CPU-Slot specs, it doesn' | ||
| |3 |Adressing the " | |3 |Adressing the " | ||
| - | |4 |Final one. In fact, it's a revision bump for clear identification from the last Rev 3 which was finally working according to specs and had no bugs found. As of the latest production run this was the factory standard. Due to internal changes, it requires FlashROM 7.1 or above (the boards come with 7.x) it definately drives you into problems, when running ( or trying to) a Rev 4 bridge with a FlashROM below 7.x. If it gets up at all with a Flash below 7.x, it may report a Rev 2 for the bridge because of internal reassignments... | + | |4 |Final one. In fact, it's a revision bump for clear identification from the last Rev 3 which was finally working according to specs and had no bugs found. As of the latest production run this was the factory standard. Due to internal changes, it requires FlashROM 7.1 or above (the boards come with 7.x) it definately drives you into problems, when running ( or trying to) a Rev 4 bridge with a FlashROM below 7.x. If it gets up at all with a Flash below 7.x, it may report a Rev 2 for the bridge because of internal reassignments... .| |
| \\ | \\ | ||
| - | ===== FlickerFixer | + | ===== FlickerFixer |
| ^Ver.^ ^ | ^Ver.^ ^ | ||
| |1 |First working version used in-house in v1.1 prototype PCBs. They never (with some exceptions) shipped.| | |1 |First working version used in-house in v1.1 prototype PCBs. They never (with some exceptions) shipped.| | ||
Last modified: 2024/09/21 23:40
Page Tools
Unless otherwise specified, the content of this wiki is published under the following license:
Attribution - Share Alike 3.0 Unported (CC BY-SA 3.0) CC Attribution-Share Alike 3.0 Unported
Attribution - Share Alike 3.0 Unported (CC BY-SA 3.0) CC Attribution-Share Alike 3.0 Unported
