A.D.A. Amiga Demoscene Archive

  Welcome guest! Please register a new account or log in

  

  

  

Demos Amiga Demoscene Archive Forum / Coding / Display differences WinUAE and real hardware

 

Author Message
noname
Member
#1 - Posted: 29 Dec 2016 19:12
Reply Quote
Did you ever find that a display/screen that works fine in WinUAE is actually diagonally distorted on real hardware?

Inspired by Subside, I was just integrating a 15 bit AGA screenmode into our existing system. This required fiddling with bplxmod. When I finally got it working in WinUAE I tested it on my A1260 and found that the display is heavily distorted. It almost looks like a badly written Kick1.2 intro running on newer Kickstarts, e.g. World of Wonders cracktro scroller, if you know what I mean.

Did anybody else witness this kind of difference? Who knows, maybe it is not even related to bplxmod, but something else - fetchmode or so?
todi
Member
#2 - Posted: 29 Dec 2016 20:18
Reply Quote
Maybe it's an memory alignment issue, for fmode >= 2 bitplane memory must be 64bit aligned.
noname
Member
#3 - Posted: 29 Dec 2016 22:51 - Edited
Reply Quote
Although my bitplane memory was 64 bit aligned, your comment pushed me in the right direction. My mode is 216x180 pixel, each of which consisting of rgb components, so actually (216*3=)648x180 hires. I already made sure each line was 32 bit aligned, but after reading your comment I thought: why not push it to 64 bit? So 256*3=768 bits per row. This somehow made me find the correct values immediately. For the record, these work for me:

dc.w $1fc,$f,$106,4
dc.w diwstrt,$4581,diwstop,$f9c1 ;16:9, 180 lines
dc.w ddfstrt,$38,ddfstop,$ca
dc.w bpl1mod,8
dc.w bpl2mod,8

Angry Retired Bastard
Member
#4 - Posted: 30 Dec 2016 18:07
Reply Quote
I've been screwed by WinUAE being "too tolerant" with ddf-settings before (ref: here) but at that point I was using a fairly old version of it.
noname
Member
#5 - Posted: 2 Jan 2017 18:50
Reply Quote
When I added a background picture I noted that I missed a row of pixels on the right side.

The 15 bit mode with Kalms c2p_4rgb888_3rgb555h8_040 writes 11 pixel-bits from a 32 bit register. It does so by omitting the blue-component of the last pixel in the register. This is actually well documented like that. Nevertheless, I still managed to mix up my math and then only looked at the custom registers when I couldn't make the black stripe go away. The solution is to make the screenbuffer 220 pixels wide, as Dodke also mentioned in the Subside thread at Pouet. This actually neatly fits the 640 screen display window, because 220*32/11=640!

This are the values for the copperlist of a 220 pixel RGB on a 640 highres screen:

dc.w $1fc,$f,$106.4
dc.w diwstrt,$4581,diwstop,$f9c1 ;16:9, 180 lines
dc.w ddfstrt,$38,ddfstop,$c0
dc.w bpl1mod,$10
dc.w bpl2mod,$10


Maybe that is helpful for someone. I actually inlined saturation into the c2p code, as proposed by Blueberry over here, and now work from a 4RGB666 buffer. This is quite a neat screenmode!

 

  Please register a new account or log in to comment

  

  

  

 

A.D.A. Amiga Demoscene Archive, Version 3.0