Unexpected LD (HL), A behavior

By fcoury

Rookie (18)

fcoury's picture

09-04-2023, 22:32

On the same vain as my last question about LDIR behavior, which wouter_ kindly responded in a very thorough fashion (thank you again btw!), I am confused about another behavior, this time about LD(HL), A.

I am seeing different behaviors from the openMSX code and mine when running it. Here's the scenario:

#0D43> list
  0D39  79          LD A, C                        
  0D3A  32 FF FF    LD (#FFFF), A                  
  0D3D  21 00 FF    LD HL, FF00                    
  0D40  3E 0F       LD A, #0F                      
  0D42  77          LD (HL), A                     
> 0D43  BE          CP (HL)                        
  0D44  20 08       JR NZ, #08                     
  0D46  2F          CPL                            
  0D47  77          LD (HL), A                     
  0D48  BE          CP (HL)                        
  0D49  20 03       JR NZ, #03                     
  0D4B  25          DEC H                          
  0D4C  18 F2       JR #F2      

I am stopped right after the LD (HL), A instruction and up to this point, all the registers, including HL and the memory location it points to were perfectly sync'ed between my emulator and openMSX.

Here's a list of the last executed instructions and how it affected some registers/flags (the status on the right of the instruction is what it looked like BEFORE the execution of the instruction):

0D43  BE          CP (HL)                        #0D43 #BE - A: #0F B: #F0 C: #F0 D: #FF E: #FF H: #7F L: #00 - HL: #7F00(#0F) SP: #FFFF - S: 0 Z: 0 H: 1 P/V: 1 N: 1 C: 0
0D42  77          LD (HL), A                     #0D42 #77 - A: #0F B: #F0 C: #F0 D: #FF E: #FF H: #7F L: #00 - HL: #7F00(#00) SP: #FFFF - S: 0 Z: 0 H: 1 P/V: 1 N: 1 C: 0
0D40  3E 0F       LD A, #0F                      #0D40 #3E - A: #F0 B: #F0 C: #F0 D: #FF E: #FF H: #7F L: #00 - HL: #7F00(#00) SP: #FFFF - S: 0 Z: 0 H: 1 P/V: 1 N: 1 C: 0
0D4C  18 F2       JR #F2                         #0D4C #18 - A: #F0 B: #F0 C: #F0 D: #FF E: #FF H: #7F L: #00 - HL: #7F00(#00) SP: #FFFF - S: 0 Z: 0 H: 1 P/V: 1 N: 1 C: 0
0D4B  25          DEC H                          #0D4B #25 - A: #F0 B: #F0 C: #F0 D: #FF E: #FF H: #80 L: #00 - HL: #8000(#F0) SP: #FFFF - S: 0 Z: 1 H: 0 P/V: 0 N: 1 C: 0
0D49  20 03       JR NZ, #03                     #0D49 #20 - A: #F0 B: #F0 C: #F0 D: #FF E: #FF H: #80 L: #00 - HL: #8000(#F0) SP: #FFFF - S: 0 Z: 1 H: 0 P/V: 0 N: 1 C: 0
0D48  BE          CP (HL)                        #0D48 #BE - A: #F0 B: #F0 C: #F0 D: #FF E: #FF H: #80 L: #00 - HL: #8000(#F0) SP: #FFFF - S: 0 Z: 1 H: 1 P/V: 0 N: 1 C: 0
0D47  77          LD (HL), A                     #0D47 #77 - A: #F0 B: #F0 C: #F0 D: #FF E: #FF H: #80 L: #00 - HL: #8000(#0F) SP: #FFFF - S: 0 Z: 1 H: 1 P/V: 0 N: 1 C: 0

As you can see from the last two statuses:

#0D42 #77 - A: #0F B: #F0 C: #F0 D: #FF E: #FF H: #7F L: #00 - HL: #7F00(#00) SP: #FFFF - S: 0 Z: 0 H: 1 P/V: 1 N: 1 C: 0
#0D43 #BE - A: #0F B: #F0 C: #F0 D: #FF E: #FF H: #7F L: #00 - HL: #7F00(#0F) SP: #FFFF - S: 0 Z: 0 H: 1 P/V: 1 N: 1 C: 0

A became 0x0F and right after the memory location pointed by HL was loaded with 0x0F.

However on openMSX this didn't happen:

Initially I thought it was becase of the memory layout, but apparently we have the same layout active, you can see openMSX's is:

$0  $0000  0
$1  $4000  0
$2  $8000  3
$3  $C000  3

And the machine descriptor:

      <primary slot="0">
        <ROM id="Temporary Machine">
          <mem base="0x0000" size="0x8000" />
          <rom>
            <sha1>2f997e8a57528518c82ab3693fdae243dbbcc508</sha1>
            <filename>/Users/fcoury/code/msx_emulator/cbios_main_msx1.rom</filename>
          </rom>
        </ROM>
      </primary>

      <primary external="true" slot="1" />

      <primary external="true" slot="2" />

      <primary slot="3">
        <RAM id="Main RAM">
          <mem base="0x0000" size="0x10000" />
        </RAM>
      </primary>

And my emulator is working the same way:

#0D44> st
Cycles: 1311
Breakpoints: []
Primary Slot Config: 11110000
Slot #0: ROM path=Some("/Users/fcoury/code/msx_emulator/cbios_main_msx1.rom") base=0x0000 size=0x8000
Slot #1: Empty
Slot #2: Empty
Slot #3: RAM base=0x0000 size=0xFFFF

Segment 0: 0x0000 - 0x7FFF - base: 0x0000 - (slot 0)
Segment 1: 0x8000 - 0xFFFF - base: 0x0000 - (slot 3)

Memory page 0 (0x0000 - 0x3FFF): primary slot 0 (ROM path=Some("/Users/fcoury/code/msx_emulator/cbios_main_msx1.rom") base=0x0000 size=0x8000)
Memory page 1 (0x4000 - 0x7FFF): primary slot 0 (ROM path=Some("/Users/fcoury/code/msx_emulator/cbios_main_msx1.rom") base=0x0000 size=0x8000)
Memory page 2 (0x8000 - 0xBFFF): primary slot 3 (RAM base=0x0000 size=0xFFFF)
Memory page 3 (0xC000 - 0xFFFF): primary slot 3 (RAM base=0x0000 size=0xFFFF)

Any ideas why doing LD (HL), A when A is 0x0F and the memory segment is mapped to RAM doesn't work?

Thank you!

Login or register to post comments

By fcoury

Rookie (18)

fcoury's picture

09-04-2023, 22:42

OK I think 0x7F00 is ROM and not RAM, am I correct? Apparently I am allowing ROM memory to be written (facepalm!).

Let's see if that was the problem Smile

EDIT: I love how describing your problem you're struggling with for a long time sometimes is the key to solving it, right?

2023-04-09T20:41:24.092179Z  WARN msx::slot: Attempt to write to ROM address 0x7F00
2023-04-09T20:41:25.518792Z  WARN msx::slot: Attempt to write to ROM address 0x7F00
2023-04-09T20:41:26.942634Z  WARN msx::slot: Attempt to write to ROM address 0x7F00
2023-04-09T20:41:28.368490Z  WARN msx::slot: Attempt to write to ROM address 0x7F00
2023-04-09T20:41:29.790200Z  WARN msx::slot: Attempt to write to ROM address 0x7F00
2023-04-09T20:41:31.376611Z  WARN msx::slot: Attempt to write to ROM address 0x7F00

That was the problem indeed Smile

By santiontanon

Paragon (1805)

santiontanon's picture

09-04-2023, 22:41

#7f00 is in page 2, which if I see correctly in the openMSX debugger, it is currently mapped to ROM, so, it is not writable, right? Hence, "ld (hl), a" has no effect.

By santiontanon

Paragon (1805)

santiontanon's picture

09-04-2023, 22:42

ah, yes, exactly, I wrote before seeing your second comment Smile

By fcoury

Rookie (18)

fcoury's picture

09-04-2023, 22:43

Yes, absolutely. I was struggling with this since yesterday and it was SO OBVIOUS. I almost deleted the post, but I think it's worth keeping around.

Thank you!

By Grauw

Ascended (10767)

Grauw's picture

09-04-2023, 22:44

You’re writing to 7F00H which is ROM, so writing to it does not change the memory?

Edit: never mind haha, you already found it Smile.

By fcoury

Rookie (18)

fcoury's picture

09-04-2023, 22:45

Grauw wrote:

You’re writing to 7F00H which is ROM, so writing to it does not change the memory?

Edit: never mind haha, you already found it Smile.

Sorry to waste your time and thank you! Smile