WinUAE 2.7.0 beta series - Page 2

Leandro Jardim · 12 July 2013, 00:37

Hi, its the first time I am using Cybergraphx 4, but I noticed that when I choose a screen with 16 colors, it opens always a high/true color screen instead. Is this normal or it is a WinUAE bug?

Also, 16 colors screens are incredibly slow. Is there anything I can do about this, maybe change a configuration in CGX, to speed-up the remapping process?

Toni Wilen · 12 July 2013, 10:31

Quote:

Originally Posted by Leandro Jardim

Hi, its the first time I am using Cybergraphx 4, but I noticed that when I choose a screen with 16 colors, it opens always a high/true color screen instead. Is this normal or it is a WinUAE bug?

256 color host mode was removed in 1.6..

Quote:

Also, 16 colors screens are incredibly slow. Is there anything I can do about this, maybe change a configuration in CGX, to speed-up the remapping process?

Compared to what? 256 color cgx? 16 color uaegfx?

Leandro Jardim · 12 July 2013, 14:10

When I change the Workbench screen to a *UAEGFX* Picasso mode with 16 colors, the PC screen is in reality at 32 bit, but the Workbench behaves exactly like it was in a 16 color screen because FullPalette shows only 16 colors. But with CyberGraphx, not... It behaves like in 24/32 bit in the sense that FullPalette shows all the 256 colors or Workbench pens.

Workbench ran a bit slow the first times I booted with 16 colors, if I compare it to CyberGraphx 24/32 bits depth. It could be a problem with my WinUAE configuration too, but the true is that after I tweaked some options in the CGX files, its now very fast.

Toni Wilen · 12 July 2013, 17:28

Quote:

Originally Posted by Leandro Jardim

When I change the Workbench screen to a *UAEGFX* Picasso mode with 16 colors, the PC screen is in reality at 32 bit, but the Workbench behaves exactly like it was in a 16 color screen because FullPalette shows only 16 colors. But with CyberGraphx, not... It behaves like in 24/32 bit in the sense that FullPalette shows all the 256 colors or Workbench pens.

I guess cgx 16 colors is only some kind of compatibility mode, 16 vs 256 colors makes no speed difference on chunky screen modes.

btw, next time include a bit more context when asking

Arnie · 14 July 2013, 10:31

I tried adding the CDTV.scsi option from the advanced settings panel and WinUAE crashed.

I have tried it on quickstart and custom configuration (3.i kick, 2.30 extended) and both crash.

I also tried this with version 2.6, so maybe it never worked?

Toni Wilen · 14 July 2013, 16:38

Quote:

Originally Posted by Arnie

I tried adding the CDTV.scsi option from the advanced settings panel and WinUAE crashed.

I have tried it on quickstart and custom configuration (3.i kick, 2.30 extended) and both crash.

I also tried this with version 2.6, so maybe it never worked?

Fixed. Extremely rarely used, I guess it broke during some SCSI emulation update.

Leandro Jardim · 15 July 2013, 02:38

When I use CGX4 with PicolloSD64 ZIII and a 24 bit screenmode the lores/hires pointer is not shown. The old beta you put before the CDTV fix not had this bug.

Toni Wilen · 15 July 2013, 12:29

Quote:

Originally Posted by Leandro Jardim

When I use CGX4 with PicolloSD64 ZIII and a 24 bit screenmode the lores/hires pointer is not shown. The old beta you put before the CDTV fix not had this bug.

Really? SD64 ZIII pointer has never worked for me. (Sprite image in VRAM is simply missing)

mark_k · 15 July 2013, 19:05

I did some testing of 2.7.0b1 with Piccolo graphics card emulation. (BTW, is there any reason why there is no Zorro III option for Piccolo emulation?)

On my system the emulated machine locks up when I change to a Picasso96 RTG mode. The RTG Workbench screen opens showing titlebar and mouse pointer, but no windows open and the pointer doesn't respond to mouse movement. I'm pretty sure it did work fine on my actual A2000 with Piccolo card. I'll try to create a hardfile which reproduces the problem.

A more concrete bug report now.

I tested the Piccolo emulation with the original Piccolo software, which uses EGS. I have a three-disk installation set, plus a "Piccolo Freshup 1 Mai 94" disk.

I created a new HDF, installed OS 3.1 then installed the Piccolo software. On bootup the screen momentarily shows some corruption (it's probably supposed to be an EGS logo). Then Workbench loads. Running a program which opens an EGS screen, or changing the Workbench to an EGS mode, shows a garbled display. While the display is garbled, the mouse pointer does seem to be displayed properly.

How garbled the display is varies depending on the screen depth. 6- and 8-bit (64 or 256 colours) screens seem partly okay but 2- and 4-bit screens are unusable. If I actually try to do much (open icons/windows etc.) with an 8-bit EGS Workbench the system seems to lock up (mouse pointer stops moving).

I can upload the Piccolo software if you don't already have it. Pics show display after changing Workbench to 640x480 at several bit depths, and after running the EGStris demo.

Toni Wilen · 15 July 2013, 19:23

Quote:

Originally Posted by mark_k

I did some testing of 2.7.0b1 with Piccolo graphics card emulation. (BTW, is there any reason why there is no Zorro III option for Piccolo emulation?)

Because some Internet Page forgot to mention Piccolo is Z2/Z3 board.

Quote:

On my system the emulated machine locks up when I change to a Picasso96 RTG mode. The RTG Workbench screen opens showing titlebar and mouse pointer, but no windows open and the pointer doesn't respond to mouse movement. I'm pretty sure it did work fine on my actual A2000 with Piccolo card. I'll try to create a hardfile which reproduces the problem.

Probably caused by unimplemented vblank interrupt. Only PicassoII+ emulation implements it. (Because it was the only one that was tested with Picasso96). It seems CGX does not need it.

Vblank interrupt is board specific, each board seems to have specific IO port that is used to enable/disable it. Needs some reverse-engineering because linux (or netbsd) does not use it.

Quote:

How garbled the display is varies depending on the screen depth. 6- and 8-bit (64 or 256 colours) screens seem partly okay but 2- and 4-bit screens are unusable. If I actually try to do much (open icons/windows etc.) with an 8-bit EGS Workbench the system seems to lock up (mouse pointer stops moving).

Perhaps it uses VGA 16 (or less) color modes which are planar and may not be fully working.

Quote:

I can upload the Piccolo software if you don't already have it. Pics show display after changing Workbench to 640x480 at several bit depths, and after running the EGStris demo.

Yes, please. I want to have exact same version as usual

mark_k · 15 July 2013, 19:41

I also tested Picasso II emulation with the v1.5 Picasso software. There also, lower bit depths appear garbled but higher ones are okay.

In RTG modes the mouse pointer isn't visible, and there's a horizontal line of corruption on the image.

Sometimes, on doing a Ctrl-A-A reset with RTG mode active, emulation seems to lock up with a black screen. Other times on resetting WinUAE crashes, reporting JIT: Can't handle access 00A97412!

8BitLineDemo works, 24BitLineDemo display is garbled. 8BitBlitterDemo causes a guru.

Toni Wilen · 16 July 2013, 18:32

Quote:

On bootup the screen momentarily shows some corruption (it's probably supposed to be an EGS logo)

It would be great to know exactly how it is supposed to look and exact resolution used. This must be some weird VGA mode.. (All non-linear VGA modes are weird in my opinion)

EDIT: I am getting somewhere, got correct graphics (qemu emulation ignores VGA "chained"/"unchained" memory stuff if writing via linear vram access functions) but palette is still wrong.

Quote:

On my system the emulated machine locks up when I change to a Picasso96 RTG mode

Fixed. Missing vblank interrupts done.

Quote:

I also tested Picasso II emulation with the v1.5 Picasso software. There also, lower bit depths appear garbled but higher ones are okay.

16 or less colors again?

Quote:

In RTG modes the mouse pointer isn't visible, and there's a horizontal line of corruption on the image.

Fixed. (VGA banking stuff is apparently needed, even when VRAM is fully linear. bleh!)

Quote:

Sometimes, on doing a Ctrl-A-A reset with RTG mode active, emulation seems to lock up with a black screen

Fixed. Hopefully.

mark_k · 16 July 2013, 19:44

Quote:

16 or less colors again?

Yes, with the Picasso software screens with depth 1-4 are garbled.

I tested the latest winuae.zip with Piccolo and Picasso96. It doesn't hang any more so I can successfully change Workbench to a P96 mode. However the colours are wrong; the R and B components are swapped. Open Palette preferences and play with the sliders to see. That problem doesn't happen with Picasso II/P96.

Maybe the Piccolo card byte-swaps the R and B lines in hardware? Since Amiga is big-endian vs PC little-endian perhaps there is some speed benefit in doing that?
Update: Same R/B swapping happens with Piccolo SD64 emulation, in all modes (8, 16, 32 bit).

Toni Wilen · 16 July 2013, 20:06

Quote:

Originally Posted by mark_k

Maybe the Piccolo card byte-swaps the R and B lines in hardware? Since Amiga is big-endian vs PC little-endian perhaps there is some speed benefit in doing that?
Update: Same R/B swapping happens with Piccolo SD64 emulation, in all modes (8, 16, 32 bit).

Yes, they have color lines swapped but it is already emulated and works fine here.

EDIT: do you have 32-bit host mode?

mark_k · 16 July 2013, 21:00

Quote:

Originally Posted by Toni Wilen

EDIT: do you have 32-bit host mode?

Yes, though note I'm testing WinUAE on Linux/Wine.

Another thing I noticed about the latest winuae.zip, could this be related? After you added an entry for Piccolo ZIII in the RTG card list, I get an Expansion Board Diagnostic screen with red background at boot time showing board 2011/81 as Defective, and in the WinUAE log output it says uaegfx.card 3.3 init @0000C574
Is that the UAE graphics card? Maybe some kind of conflict with the Piccolo card, e.g. if the UAE card doesn't need R/B swapping and Piccolo does? That doesn't explain why I don't see the swapped palette with emulated Picasso II though.

Toni Wilen · 16 July 2013, 21:25

Quote:

Originally Posted by mark_k

Yes, though note I'm testing WinUAE on Linux/Wine.

Another thing I noticed about the latest winuae.zip, could this be related? After you added an entry for Piccolo ZIII in the RTG card list, I get an Expansion Board Diagnostic screen with red background at boot time showing board 2011/81 as Defective, and in the WinUAE log output it says uaegfx.card 3.3 init @0000C574
Is that the UAE graphics card? Maybe some kind of conflict with the Piccolo card, e.g. if the UAE card doesn't need R/B swapping and Piccolo does? That doesn't explain why I don't see the swapped palette with emulated Picasso II though.

Set your RTG board setting again, it was reset if you had Piccolo ZII set.

Picasso II/II+ does not do hardware color component swap. (and I still can't see any wrong colors)

Toni Wilen · 16 July 2013, 21:52

EGS appears to work now. Yet another qemu blit emulation bug. (Blitter didn't start at all if it was in reset state). EGS boot screen palette is still blue but WB screen modes work.

PeterK · 17 July 2013, 08:54

Quote:

Originally Posted by Toni Wilen

Picasso II/II+ does not do hardware color component swap. (and I still can't see any wrong colors)

Hello Toni,
first, a big THANK YOU for all your work and all the new features you've introduced to WinUAE

With the new PicassoII+ emulation I was finally able to find a bug in the CGX software without owning any related real Amiga hardware (a bug in the ReadPixelArray() function trashes D2). With the help of your latest WinUAE 2.7 beta I could fix it.

Concerning the red-blue color swap: I also noticed that in the Spectrum and the Piccolo emulation in HiColor, TrueColor and 8-bit modes. Which infos do you need? The colors in PicassoII+ are correct.

Toni Wilen · 17 July 2013, 09:32

Quote:

Originally Posted by PeterK

Hello Toni,
first, a big THANK YOU for all your work and all the new features you've introduced to WinUAE

With the new PicassoII+ emulation I was finally able to find a bug in the CGX software without owning any related real Amiga hardware (a bug in the ReadPixelArray() function trashes D2). With the help of your latest WinUAE 2.7 beta I could fix it.

Nice. I guess no has used ReadPixelArray() until now

Quote:

Concerning the red-blue color swap: I also noticed that in the Spectrum and the Piccolo emulation in HiColor, TrueColor and 8-bit modes. Which infos do you need? The colors in PicassoII+ are correct.

I can't see any other reason than output display mode being 16 bit (CL emulation only supports RGB byte swapping in 32-bit mode)

Check log and make sure it says "D3D9Ex: 640*480 main texture, depth 32", depth 32 is the important bit.

PeterK · 17 July 2013, 10:06

You're right Toni !!
Exactly, the missing 32 was the reason. I was using the 16 bit host mode. With 32 bit host mode the colors are correct now. Thanks a lot again.

14 July 2013, 10:31	#25
Arnie R.I.P Smudge 18-08-16 Join Date: Aug 2005 Location: Leicester/UK Age: 66 Posts: 3,968	I tried adding the CDTV.scsi option from the advanced settings panel and WinUAE crashed. I have tried it on quickstart and custom configuration (3.i kick, 2.30 extended) and both crash. I also tried this with version 2.6, so maybe it never worked? Last edited by DH; 07 September 2016 at 16:51.

15 July 2013, 19:05	#29
mark_k Registered User Join Date: Aug 2004 Location: Posts: 3,335	I did some testing of 2.7.0b1 with Piccolo graphics card emulation. (BTW, is there any reason why there is no Zorro III option for Piccolo emulation?) On my system the emulated machine locks up when I change to a Picasso96 RTG mode. The RTG Workbench screen opens showing titlebar and mouse pointer, but no windows open and the pointer doesn't respond to mouse movement. I'm pretty sure it did work fine on my actual A2000 with Piccolo card. I'll try to create a hardfile which reproduces the problem. A more concrete bug report now. I tested the Piccolo emulation with the original Piccolo software, which uses EGS. I have a three-disk installation set, plus a "Piccolo Freshup 1 Mai 94" disk. I created a new HDF, installed OS 3.1 then installed the Piccolo software. On bootup the screen momentarily shows some corruption (it's probably supposed to be an EGS logo). Then Workbench loads. Running a program which opens an EGS screen, or changing the Workbench to an EGS mode, shows a garbled display. While the display is garbled, the mouse pointer does seem to be displayed properly. How garbled the display is varies depending on the screen depth. 6- and 8-bit (64 or 256 colours) screens seem partly okay but 2- and 4-bit screens are unusable. If I actually try to do much (open icons/windows etc.) with an 8-bit EGS Workbench the system seems to lock up (mouse pointer stops moving). I can upload the Piccolo software if you don't already have it. Pics show display after changing Workbench to 640x480 at several bit depths, and after running the EGStris demo. Attached Thumbnails

15 July 2013, 19:41	#31
mark_k Registered User Join Date: Aug 2004 Location: Posts: 3,335	I also tested Picasso II emulation with the v1.5 Picasso software. There also, lower bit depths appear garbled but higher ones are okay. In RTG modes the mouse pointer isn't visible, and there's a horizontal line of corruption on the image. Sometimes, on doing a Ctrl-A-A reset with RTG mode active, emulation seems to lock up with a black screen. Other times on resetting WinUAE crashes, reporting JIT: Can't handle access 00A97412! 8BitLineDemo works, 24BitLineDemo display is garbled. 8BitBlitterDemo causes a guru. Attached Thumbnails Last edited by mark_k; 15 July 2013 at 20:03.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
WinUAE 2.5.1 beta series	Toni Wilen	support.WinUAE	69	22 December 2012 10:22
WinUAE 2.3.3 beta series	Toni Wilen	support.WinUAE	124	17 September 2011 15:48
WinUAE 2.3.2 beta series	Toni Wilen	support.WinUAE	79	31 May 2011 19:39
WinUAE 2.3.0 beta series (was 2.2.1)	Toni Wilen	support.WinUAE	229	22 September 2010 19:20

12 July 2013, 00:37	#21
Leandro Jardim Registered User Join Date: Nov 2009 Location: Legoland Age: 45 Posts: 1,461	Hi, its the first time I am using Cybergraphx 4, but I noticed that when I choose a screen with 16 colors, it opens always a high/true color screen instead. Is this normal or it is a WinUAE bug? Also, 16 colors screens are incredibly slow. Is there anything I can do about this, maybe change a configuration in CGX, to speed-up the remapping process?

12 July 2013, 14:10	#23
Leandro Jardim Registered User Join Date: Nov 2009 Location: Legoland Age: 45 Posts: 1,461	When I change the Workbench screen to a UAEGFX Picasso mode with 16 colors, the PC screen is in reality at 32 bit, but the Workbench behaves exactly like it was in a 16 color screen because FullPalette shows only 16 colors. But with CyberGraphx, not... It behaves like in 24/32 bit in the sense that FullPalette shows all the 256 colors or Workbench pens. Workbench ran a bit slow the first times I booted with 16 colors, if I compare it to CyberGraphx 24/32 bits depth. It could be a problem with my WinUAE configuration too, but the true is that after I tweaked some options in the CGX files, its now very fast.

15 July 2013, 02:38	#27
Leandro Jardim Registered User Join Date: Nov 2009 Location: Legoland Age: 45 Posts: 1,461	When I use CGX4 with PicolloSD64 ZIII and a 24 bit screenmode the lores/hires pointer is not shown. The old beta you put before the CDTV fix not had this bug.

16 July 2013, 21:52	#37
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,506	EGS appears to work now. Yet another qemu blit emulation bug. (Blitter didn't start at all if it was in reset state). EGS boot screen palette is still blue but WB screen modes work.

17 July 2013, 10:06	#40
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,365	You're right Toni !! Exactly, the missing 32 was the reason. I was using the 16 bit host mode. With 32 bit host mode the colors are correct now. Thanks a lot again.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)