A.D.A. Amiga Demoscene Archive

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?

Maybe it's an memory alignment issue, for fmode >= 2 bitplane memory must be 64bit aligned.

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:

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.

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:


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!

BTW, talking about UAE being too tolerant, do anyone report these bugs to Toni Willen? ;)

I also had this crazy random idea of incorporating a "custom chipset validator" mode UAE. As an orga, I see people struggling with getting their stuff running on actual hardware, it would be neat if UAE warned somehow, like there was a "developer mode", which would be like "ok, you're writing X to this register, but this won't work on AGA, because you're not setting bit X to 0" or "you are using unaligned data, where only aligned data is allowed", etc. Also, it could even have something like Enforcer, traversing the OS memory lists on reads/writes and noticing writes/reads outside allocated memory, unaligned reads/writes, etc.

Also I've seen UAE supporting blits from Fast RAM, IIRC... (via some OS functions, without RTG installed, of course).

I'm sure it would be too slow for actual users, but for devs would be tremendous help for making demos (especially right before/after the deadline), because I just saw too many efforts fail on real hardware, and being a nightmare to debug... :)

It could also start small, just covering the most obvious cases,and grow eventually, maybe serving as a "knowledge base"... And of course would also help fixing the emulation issues, eventually.

it's a great idea to create a developer layer. Some simple tweaks would be to report misaligned pointers used with fetch modes requiring a particular alignment. The source is open though so its free for anyone who wants to start.

Some prods might be using undefined behaviour for effects or unconciously though.

An amiga valgrind would be a lifesaver. Valgrind is an x86/arm emulator I've heard that tracks undefined memory using x-propagation amongst other things. Also tracks allmemory reads and writes per assembly instruction.

Differences I've noticed on UAE, and even sometimes on "Indivision 2":

- Real Hardware wants 4b or 8b alignment with special fmodes., UAE doesn't care.
- UAE won't use the 2bits of sub-pixels horizontal scrolls on BPLCON1.
- There is apparently a horizontal resolution sprite bug sometimes with AGA. You have to enable a bit in BPLCON4 in AGA to assure sprites are low res, If i remember well. Concretly: with protracker, the cursor sprites is sometimes hires while should be low res. Never seen on real hardware.

I haven't tried but I'd imagine if you set hires mode it'll scroll by hires pixels?

I was thinking to use a mode for some 030 effects that has a 4bpl 320px wide image shown in both odd and even bitplanes, offsetting the other one by 1 hires pixel and setting the palette so that the hardware gives 'free' blending to 640px. This doesn't work in the emulator of course as UAE ignores the (s-)hi res scroll bits in low res.

Cool idea! I think enabling 64 bit fmode alone enables the finegrained scroll. Even in lores... but I didn't try what you propose either