Alpine9000 test #10 fails

[dirkwhoffmann]

Alpine9000 test #10 fails

[alpine9000]

Hi guys, I’m sure I can help you sort out the issues. I haven’t looked at the stuff for a few years, so give me a few days and I’ll see what I can do.

[alpine9000]

My screenshots probably would have been taken using fs-uae but it's possible some of them might have been taken using SAE. When I took those screen shots I never imagined someone using them to compare the accuracy of a new emulator :)

[alpine9000]

I commited some changes to the repo to make it easier (for me to build) as well as I hope the missing example ADF files. Let me know if you need help getting it to build.

See alpine9000/amiga_examples#1 for more details

[mithrendal]

I will give vscode-amiga-assembly a try ...

[mithrendal]

I have it in vscode-amiga-assembly now and vscode-amiga-assembly seems to be happy with it... (no errors or warnings) ... But only now I began to realize that the images (e.g. the pictures) are missing... I first have to convert them with the mac console program imagecon. The source code of that program is also in https://github.com/alpine9000/amiga_examples ... I have to compile that first ... before I can assemble the test#10

[dirkwhoffmann]

With the latest code change, Shrinkler compiles without any issue 👍.

I checked the PixelPacket red, green, and blue values. They are 16 bit (on my machine), so the following code change worked for me:

 for (i = 0; i < endw; i++) {
      PixelPacket pixel = AcquireOnePixel(image.resizeImage, i-10, line-startLine, NULL);
      printf("\tdc.w COLOR00,$%x%x%x\n", pixel.red>>12, pixel.green>>12, pixel.blue>>12);
}

Furthermore, I replaced GetOnePixel(...) by AcquireOnePixel(...), because GetOnePixel(...) has been marked as deprecated.

Looks as expected now 😃:

[mithrendal]

Hi dirk
I just tried the test cases and am in love with this switch...

it looks so nice and when you switch it on it just looks lovely.

BTW: from which machine has alpine9000 taken the reference pics ?

🤔 Maybe there are even speed differences in the Amiga family, e.g. a 4000 produces different results as a A500 MMSE . A NTSC machine has maybe different timings as a PAL machine ?

I am overly suspicious now, because you know ... of the two days you recently hunted the phantom 👻...

😄Maybe vAmiga produces the very correct results in this case too? Could you feed your goat-tek in the A500MMSE with it ?

There is of course also the possibility that we will get a third truth ... e.g. A500MMSE produces different results to vAmiga and alpine9000 ref pics... 🤣

[dirkwhoffmann]

a 4000 produces different results as a A500 MMSE

You're right. I'd better feet the goat 🐐. Stay tuned...

[mithrendal]

it looks complicated to get that makefile run...

what do you think of an alternative work around way ...

I looked at the sources and the makefile

NUM_COLORS is translated to SCREEN_BIT_DEPTH which is only used in
blit.s as a constant...

so we might patch that number in the debugger

( address 7008A is the first highlighted occurrence in)
the corresponding lines in blit.s programmcode

where SCREEN_WIDTH_BYTES is 320/8= 40 = $28

SCREEN_WIDTH		equ 320
SCREEN_HEIGHT		equ 256
SCREEN_WIDTH_BYTES	equ (SCREEN_WIDTH/8)

so with NUM_COLORS=1
7008A: move.w #$28,d3

so with NUM_COLORS=2
7008A: move.w #$50,d3

and so on...

this would be not so difficult, but there are still 3 other positions in blits.s where SCREEN_BIT_DEPTH is used

all 4 positions:
74: move.w #SCREEN_WIDTH_BYTESSCREEN_BIT_DEPTH,d3
82: move.w #(BLIT_BOB_HEIGHT64SCREEN_BIT_DEPTH)<<6|(BLIT_BOB_WIDTH64_WORDS),BLTSIZE(a6)

133:move.w #SCREEN_WIDTH_BYTESSCREEN_BIT_DEPTH,d3
140:move.w #(BLIT_BOB_HEIGHT64SCREEN_BIT_DEPTH)<<6|(BLIT_BOB_WIDTH64_WORDS),BLTSIZE(a6)

where 74 is the same as 133
and 82 is the same as 140

so we must calculate 2 values and patch them in 4 code positions

EDIT: vAmigas debugger does not allow me to alter the code (only a disassembler). Although it allows me to alter the value of 68k register d3 to $50, it is not helping because in the next loop it will get resetted to $28 ...
Maybe this workaround is a dead end ? 😟

[dirkwhoffmann]

vAmigas debugger does not allow me to alter the code (only a disassembler)

Yes. The CPU instructions cannot be modified, because it would required a complicated parser for 68k assembler. Originally, I did plan to make the registers editable, but I think I have to remove this (yet not working) feature. The problem here is as follows: When the emulator is in pause mode, the CPU is "released" and can be used by other emulator instances. When "continue" is hit, the CPU restores the old CPU state which may have been modified by another emulator instance in the meantime. Hence, the old value of $28 is restored in your example.

I also planned to make, e.g., the color registers editable in the debugger, but this doesn't work as well. It doesn't work because most programs (including AmigaOS) restore the color register values in their Copper lists after each frame. Bottom line: vAmiga's inspector (debugger) will be mostly a viewer (because of the particular design of the Amiga).

The Copper lists are different, because they are usually not modified in the middle of a program.
I could make them editable, but this would only be a weak workaround for some special scenarios.

Being able to compile the Alpine9000 test suite would be better, because these programs can serve as an excellent basis for own experiments. The good thing about these tests is that they quickly produce a bootable ADF. The turnaround time is therefore very low.

Looking at

https://github.com/alpine9000/amiga_examples/blob/master/doc/BuildingCrossDev.md

is seems that a lot of tools have to be installed. Maybe it's best to set up a Linux virtual machine and try to compile it there. Otherwise, there is a risk to overwrite parts of the standard tool chain that is installed by macOS's Xcode.

[dirkwhoffmann]

Another attempt would be to see if the (core of the) Alpine9000 example programs can be compiled with the vscode-amiga-assembly tool. I haven't had time to look into this yet.

[mithrendal]

I kind of gave up ! 😣 This makefile for the imagecon tool makes a lot of trouble on my setup... I cried for help...

alpine9000/amiga_examples#1

maybe @alpine9000 has it still somewhere in a folder ....

[dirkwhoffmann]

@alpine9000 is our last hope 😬.

[mithrendal]

Love it. That looks super neat. Now lets see what vAmiga does with it...😀

[dirkwhoffmann]

Hi Alpine9000,

I commited some changes to the repo to make it easier (for me to build)

this is great news 😀.

Unfortunately, I am still struggling with compiling the project. I guess it's due to some configuration issues on my machine.

I started with this:

cd 001.simple_image/
make

And got the following:

make -C ../tools/imagecon
gcc -c -Werror -pedantic-errors -Wfatal-errors -Wall  -Wextra -Wno-unused-parameter -Wshadow -limagequant -Wno-unused-command-line-argument -Wno-ignored-attributes -O3  imagecon.c -o out/imagecon.o 
In file included from imagecon.c:5:
./imagecon.h:11:10: fatal error: 'png.h' file not found with <angled> include;
  use "quotes" instead

This one was easy to fix. I replaced <png.h> by "png.h". However, I am puzzled why I am getting this error, because you are not. When I type in gcc -v, it shows me that LLVM is used (the same backend shows up when I type in clang -v):

Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1
Apple LLVM version 10.0.1 (clang-1001.0.46.4)
Target: x86_64-apple-darwin18.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin 

After replacing <png.h> by "png.h", I got:

gcc -c -Werror -pedantic-errors -Wfatal-errors -Wall  -Wextra -Wno-unused-parameter -Wshadow -limagequant -Wno-unused-command-line-argument -Wno-ignored-attributes -O3  imagecon.c -o out/imagecon.o 
In file included from imagecon.c:5:
In file included from ./imagecon.h:11:
./png.h:4:10: fatal error: unknown type name 'imagecon_image_t'
png_read(imagecon_image_t* ic, char* file_name);

The unknown struct imagecon_image_t is defined inimagecon.h, but below the statement for including png.h. So I makes sense for me that the struct is undefined at this point.

Interestingly, #include "png.h"appears a second time in imagecon.h, below the declaration of imagecon_image_t 🤔. Can you help?

[alpine9000]

I think it's because you need to install libpng which should be in /usr/local/include (or somewhere in the system search path).

so:

#include <png.h> // libpng header
#include "png.h" // imagecon png.h header

You can either build it from the sources or install it with brew (I am guessing).

There are other prerequisite libs you will need

pngquant (git://github.com/pornel/pngquant.git)
GraphicsMagick
TMX C Loader (https://github.com/alpine9000/tmx)

[dirkwhoffmann]

It seems like the amigaos-cross-toolchain cannot be compiled on Mojave.

DEBUG: changing environment variable "CC" to "/usr/bin/clang -m32 -std=gnu11"

It requires to build a 32 bit app which is no longer supported (at least not out of the box):

ld: warning: The i386 architecture is deprecated for macOS (remove from the Xcode build setting: ARCHS)
ld: warning: ignoring file  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/lib/libSystem.tbd, missing required architecture i386 in file /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/lib/libSystem.tbd
ld: dynamic main executables must link with libSystem.dylib for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
*** The command '/usr/bin/clang -m32 -std=gnu11 -o conftest -g -O2 -Wall   conftest.c' failed.
*** You must set the environment variable CC to a working compiler.

[alpine9000]

In order to build these examples you will only need vasm, vlink and the NDK:

curl -OL http://sun.hasenbraten.de/vasm/release/vasm.tar.gz
tar zxfv vasm.tar.gz
cd vasm
make CPU=m68k SYNTAX=mot
cp vasmm68k_mot /usr/local/bin

curl -OL http://sun.hasenbraten.de/vlink/release/vlink.tar.gz
tar zxfv vlink.tar.gz`
cd vlink
mkdir objects
make
cp vlink /usr/local/bin

curl -OL http://www.haage-partner.de/download/AmigaOS/NDK39.lha
lha x NDK39.lha
cp -r NDK_3.9/Include/include_i/* /usr/local/amiga/vgcc/ndk/include/
cp -r NDK_3.9/Include/include_h/* /usr/local/amiga/vgcc/ndk/include/
cp -r NDK_3.9/Include/linker_libs/* /usr/local/amiga/vgcc/ndk/lib

[dirkwhoffmann]

Thanks a lot 😀, copying the include files to vgcc was the missing part on my side. Now, I can compile all tests except:

#016.copper_fun
#020.shrinkler

Errors for copper_fun:

vasmm68k_mot -Fhunk -quiet -esc -DFRAMERATE=10 copper_fun.s -o out/main.o -I/usr/local/amiga/vgcc/ndk/include/

error 2040 in line 3 of "out/copper-new.s": data out of range
included from line 74 of "copper_fun.s"
>	dc.w COLOR00,$62b2c6fe

error 2040 in line 4 of "out/copper-new.s": data out of range
included from line 74 of "copper_fun.s"
>	dc.w COLOR00,$62b2c6fe

error 2040 in line 5 of "out/copper-new.s": data out of range
included from line 74 of "copper_fun.s"
>	dc.w COLOR00,$62b2c6fe

error 2040 in line 6 of "out/copper-new.s": data out of range
included from line 74 of "copper_fun.s"
>	dc.w COLOR00,$62b2c6fe

error 2040 in line 7 of "out/copper-new.s": data out of range
included from line 74 of "copper_fun.s"
>	dc.w COLOR00,$62b2c6fe

(Should be dc.l? 🤔)

Errors for shrinkler:

vasmm68k_mot -Fhunk -quiet -esc -DSHRINKLER=1 -DDECOMPRESS_ADDRESS="\$10000" -DUSERSTACK_ADDRESS="\$" -DBASE_ADDRESS="\$50000"  ../shared/shrinkler_bootblock.s -o out/bootblock.o -I/usr/local/amiga/vgcc/ndk/include/ -I../include

fatal error 13 in line 1 of "shrinkler_bootblock.s": could not open <funcdef.i> for input
>	include "funcdef.i"

[alpine9000]

I have pushed a fix for the shrinkler error.

The copper_fun problem is a bit strange. This is a problem caused by copper_fun_generate.c outputting invalid data. It should definitely only be a word length data.

The code below is what outputs the asm code in out/copper-new.s. Granted the right shifts instead of divides is wrong and should really be /16 (you could try that), but the next thing would be to either debug this program or output the raw values of "pixel"

for (i = 0; i < endw; i++) {
      PixelPacket pixel = GetOnePixel(image.resizeImage, i-10, line-startLine);
      printf("\tdc.w COLOR00,$%x%x%x\n", pixel.red>>4, pixel.green>>4, pixel.blue>>4);
    }

[dirkwhoffmann]

I've just compared vAmiga's new slow Blitter agains the reference pics:

It shows that vAmiga's slow Blitter is a little bit too fast, but within the bounds we can accept at this early development stage. There is strong indication that the basic delay architecture is working in vAmiga which is the important fact for now.

BTW, vAmiga allows the user to switch the Blitter accuracy while the emulator is running which is quite nice. If one reverts to level 0, the picture changes immediately.

@alpine9000: Thanks again for developing these tests and helping me in compiling them on my machine. Your tests have turned out to be invaluable for me, especially because I was able to use them as the basis for creating own tests. There is a steadily growing Github repo called vAmigaTS which I use to collect all test cases.

https://github.com/dirkwhoffmann/vAmigaTS

All test cases have been developed on top of the framework you've created.

[dirkwhoffmann]

Here we go... fresh images computed on the A500MMSE.

Interestingly, it doesn't seem to be 100% identical. Here is Alpine's reference image of the 32 color version:

I'm a little puzzled about the 8 color version which wasn't among the pictures shown so far. It is displayed below. The MMSE shows the same timing as Alpine's machine, but the image itself looks different. Now the confusion is complete 🙃.

Alpine's machine:

A500 MMSE:

[mithrendal]

That is a very good thing that alpines pics are not from a real machine. Then we hopefully only have one truth.

[dirkwhoffmann]

I'll try with fs-uae later. Do you know if fs-uae is like WinUAE compatibility wise, or am I better off using WinUAE?

[Alessandro1970]

WinUAE

[mithrendal]

Frode Solheim bases his FSUAE completely on the WinUAE Core. As I understood it, he has built an platform independend user interface for it. I don't know whether he exposes all WinUAE compatibility settings to the FSUAE user-interface...

In contrast SAE as I understood it, is a Javascript port of the c-code of WinUAE, whereas FSUAE uses exactly the same c-code.

despite that I am using FSUAE for years now... Until recently when I switched to vAmiga...😎