[hackfleisch]

Thanks AWJ. I must have read a wrong opcode description. "RLA" rotate A through carry.
But the command "RL C" will also rotate through carry, so the carry is "mixed" with both values.

Lets play this through:
First logo byte is CEh, so sub is called with
A=1100 1110
C=A = 1100 1110
assume carry=0
(register shown after the corresponding RL command. The carry is given after the comma)
1. iteration of loop
C=1001 1100, 1
A=1001 1101, 1
C=1001 1101, 1
A=0011 1011, 0

2. iteration of loop
C=0011 1010, 1
A=0111 0111, 0
C=0011 1010, 1
A=1110 1111, 0

3. iteration of loop
C=0111 0100, 0
A=1101 1110, 1
C=0111 0101, 0
A=1011 1100, 1

4. iteration of loop
C=1110 1011, 0
A=0111 1000, 1
C=1110 1011, 0
A=1111 0000, 0

So indeed, the bits of the first nibble are doubled and fill up the whole byte of A. This is written to address in HL and HL+2, which makes up the "color" in 2bpp mode. So the color is always 11 or 00 which means black or white.

The next call goes on line after the first, to address 96h. Here carry, A and C register are untouched from previous loop. But what happens with the lower nibble of the source logo byte CE?

[AWJ]

Thanks AWJ. I must have read a wrong opcode description. "RLA" rotate A through carry.
But the command "RL C" will also rotate through carry, so the carry is "mixed" with both values.

Lets play this through:
First logo byte is CEh, so sub is called with
A=1100 1110
C=A = 1100 1110
assume carry=0
(register shown after the corresponding RL command. The carry is given after the comma)
1. iteration of loop
C=1001 1100, 1
A=1001 1101, 1
C=1001 1101, 1
A=0011 1011, 0

2. iteration of loop
C=0011 1010, 1
A=0111 0111, 0
C=0011 1010, 1
A=1110 1111, 0

3. iteration of loop
C=0111 0100, 0
A=1101 1110, 1
C=0111 0101, 0
A=1011 1100, 1

4. iteration of loop
C=1110 1011, 0
A=0111 1000, 1
C=1110 1011, 0
A=1111 0000, 0

So indeed, the bits of the first nibble are doubled and fill up the whole byte of A. This is written to address in HL and HL+2, which makes up the "color" in 2bpp mode. So the color is always 11 or 00 which means black or white.

The next call goes on line after the first, to address 96h. Here carry, A and C register are untouched from previous loop. But what happens with the lower nibble of the source logo byte CE?

At the end of four iterations of the loop, the upper four bits of the original source byte have been doubled and shifted into A, and the lower four bits of the original source byte are now in the upper four bits of C. So the second call to 0096 is what handles them.

[hackfleisch]

I tried many GB emulators but none of them seems to emulate the boot-phase of the DMG. I do not see the scrolling "Nintendo(R)" Logo, nor hear any sound. They just start over with the game.
For my tests and learnings it would be great to know one emu doing that.
Any hints for me?
March 21, 2016, 07:54:00 am - (Auto Merged - Double Posts are not allowed before 7 days.)

At the end of four iterations of the loop, the upper four bits of the original source byte have been doubled and shifted into A, and the lower four bits of the original source byte are now in the upper four bits of C.
So the second call to 0096 is what handles them.

Right, as you can see in my "debug" post:
A at start = 1100 1110
A at end = 1111 0000
C at end = 1110 1011

So the second call to 0096 is what handles them.

So, register C is only used to produce side-effects on the carry, and keeps the lower nibble of the current logobyte between iterations, right?
The persistence of registers is what makes Assembler really hard to debug. It's like super-globals in other languages.

[AWJ]

I tried many GB emulators but none of them seems to emulate the boot-phase of the DMG. I do not see the scrolling "Nintendo(R)" Logo, nor hear any sound. They just start over with the game.
For my tests and learnings it would be great to know one emu doing that.
Any hints for me?
March 21, 2016, 07:54:00 am - (Auto Merged - Double Posts are not allowed before 7 days.)Right, as you can see in my "debug" post:
A at start = 1100 1110
A at end = 1111 0000
C at end = 1110 1011
So, register C is only used to produce side-effects on the carry, and keeps the lower nibble of the current logobyte between iterations, right?
The persistence of registers is what makes Assembler really hard to debug. It's like super-globals in other languages.

bgb can run the bootrom if you have a copy of it. Check "enable bootrom" in the options.

In high-level language terms, CPU registers can be function arguments, return values, and/or local variables. And subroutines can and often do have multiple entry points (e.g. 0095 and 0096 in the bootrom code) If you write two very similar functions in C or C++, the compiler can often compile it as a single function with two entry points.

[hackfleisch]

bgb can run the bootrom if you have a copy of it. Check "enable bootrom" in the options.

First, thank you so much for your explainations.
I tried to enable the bootrom, and also assign a bootrom file, but it behaves like bevor. No intro screen with scrolling shown.

I did see the tiles of the logo in VRAM, and also see the logo for a millisecond or so on screen. But not the scrolling logo like on the native hardware DMG.

What do i do wrong?

[AWJ]

First, thank you so much for your explainations.
I tried to enable the bootrom, and also assign a bootrom file, but it behaves like bevor. No intro screen with scrolling shown.

I did see the tiles of the logo in VRAM, and also see the logo for a millisecond or so on screen. But not the scrolling logo like on the native hardware DMG.

What do i do wrong?

You have to put the bootrom in the same folder as the emulator (not the same folder as your game ROMs). And it can't be in a zip or other archive.

[hackfleisch]

You have to put the bootrom in the same folder as the emulator (not the same folder as your game ROMs)

That did it! 
I've downloaded DMG_ROM.bin here [ from a website ], put it into the BGB program dir and enter the filename in bgb control panel "System" into the "DMG bootrom" box. Also check the "bootroms enabled" option. Works like charm! Now i can use BGB's debugger to see what's going on.

After getting the scroll down Nintendo-logo on screen, i started to modify it. My goal was to change des logo, just to see it on the screen. Of course it would never go past the logo-check subroutine, but this was no matter for me.

I found a great web-based online generator for it [ also on a website ]. The tool is written in JavaScript and gives a ROM-file as result.

After getting a big grin, while watching my own custom logo scrolling into screen, my next goal is to learn about displaying graphics. I've read about tiles, tilemaps, background memory and windowposition. I think i could not be so hard to write some ASM code to display some tiles on the screen.

For now i'm looking for good development tools to code and compile in Assembler.

By the way, i would like to say that i REALLY appreciate the help i'm getting here. Instead of flaming and hating dump newbes like me, you and the other members here, answer professional and clearly. Besides this it makes much fun to hack inside this old consoles!