Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MAP upper bytes not working as expected #838

Open
dansanderson opened this issue Oct 1, 2024 · 4 comments
Open

MAP upper bytes not working as expected #838

dansanderson opened this issue Oct 1, 2024 · 4 comments
Labels
new New report, not classified yet

Comments

@dansanderson
Copy link
Collaborator

Test Environment (required)
You can use MEGA65INFO to retrieve this.

  • Platform: MEGA65R6
  • Core Commit: 3c10488 (v0.96)
  • ROM Release: 920408

Describe the bug
Setting MAP upper bytes, such as to map 16-bit addresses to Attic RAM, does not appear to be working correctly.

I believe I tested the Memory chapter thoroughly including an example of mapping A000-BFFF to 800.0000 with an offset of 7FF.6000 (MAPH = 7F.F60(00) region 2), so if we can confirm that our tests are correct, then we should look for a recent regression.

I attempted to reproduce using short assembly language programs entered into the MONITOR but could not get any example to work. It's possible I'm doing it incorrectly and my test needs troubleshooting. As follows:

MONITOR
A1600 SEI
LDA #$00
LDX #$00
LDY #$80
LDZ #$0F
MAP
LDY #$00
LDZ #$21
MAP
EOM
LDA #$BB
STA $A000
STA $A001
STA $A002
JMP $161B

G1600

In Matrix Mode, this correctly shows the code in an infinite loop at $161B, with the lower bytes of MAPH set to $2100 and MAPL to $0000. The Matrix mode debugger does not display the upper bytes of the MAP register; this is expected to set MAPH upper to $80, for a total offset of 801.0000 added to A000-BFFF.

Expected: m801a000 should show BB BB BB, as should m777a000.
Actual: Both show 00 00 00.

@Pimau tried to affect a similar change via m65dbg and says this example mapping of A000 to 801.A000 is working, but A000 mapped to 800.0000 (offset 7FF.6000) is not working. The latter is the example from the Memory chapter. MEGA65/mega65-rom-public#172

@dansanderson
Copy link
Collaborator Author

IMG_0070

(Screenshot of my test attempt in case I messed it up. :) )

@Pimau
Copy link

Pimau commented Oct 6, 2024

Hi!
As promised in my first ticket regarding this issue (MEGA65/mega65-rom-public#172), I made a bunch of more tests to proof the hypothesis I mentioned in the former ticket.

This time I made very sure, that several aspects were always the same:

  • All tests coded and compiled with ACME, no jobs by hand in the MONITOR etc.
  • I mapped a special byte stream to make sure that mdump is not by mistake showing an equal memory portion (this happens quite often when you are addressing Attic and is maybe the reason why we often see, that the sample code of the manual is working?!)
  • I always restarted the machine with a new test to make sure that no memory lefties of the last test were appearing
  • I tested all aspects/combinations of values for MAPLO and MAPHI, taking edge cases for source address, offset high byte, MSB and bank for almost all available sections
  • Same config as the initial ticket

Outcome:
The only pattern which always stayed true in all my tests: The MAP fails, if the addressed source part of the memory is "pulled" down to an offset which is smaller in its high-byte than the source memory we are mapping. Three sample tests which are visualizing this, to make it better understandable:

Working

  • Source: $812.B000
  • Target: $A000
  • Offset = $812.1000
  • High byte of offset = $81
  • Standard special value = $0F
  • MSB of 16-bit = $10
  • Bank = $2
  • Nibble value for segment selection MAPHI = $2
  • MAPH = 2210

Not working

  • Source: $810.9000
  • Target: $A000
  • Offset = $80F.F000
  • High byte of offset = $80
  • Standard special value = $0F
  • MSB of 16-bit = $90
  • Bank = $0
  • Nibble value for segment selection MAPHI = $2
  • MAPH = 2090

Working

  • Source: $810.9000
  • Target: $8000
  • Offset = $810.1000
  • High byte of offset = $81
  • Standard special value = $0F
  • MSB of 16-bit = $10
  • Bank = $0
  • Nibble value for segment selection MAPHI = $1
  • MAPH = 1010

I hope this helps when somebody is addressing the issue. I'll keep the test code in commented state in my program, so that I can help with testing when the time comes.

@dansanderson
Copy link
Collaborator Author

@Pimau Can you attach your test code to this ticket?

@Pimau
Copy link

Pimau commented Oct 8, 2024

Sure. I am using the infrastructure of my current project to place an expected byte-stream with DMA in Attic before the test. These routines have too much dependencies to paste them here in a clear format. But finally, after sorting memory contents, I call this routine and sbreak directly after it (see comment). Basically nothing you can't write in minutes.

copa_mapAtticTest    ; MAP Attic to 16-bit space (MAPHI)
	
	lda #$00     ; No mapping in MAPLO
	ldx #$00
	
	ldy #$81     ; High byte of offset for MAPHI
	ldz #$0F     ; Special value
	map          ; first MAP
                     ; A+X still 0; MAPLO off
	ldy #$10     ; MSB of 16-bit
	ldz #$10     ; segment selection nibble + offset bank nibble
	MAP          ; second MAP
	EOM
	
	ldy #$16     ; Puts MAPL/MAPH in $1600-1603 = X,A,Z,Y
                     ; $1604 = MB byte for MAPLO 
                     ; $1605 = MB byte for MAPHI
	lda #$74     ; trap: hyppo_get_mapping
	sta $D640    ; execute
	clv
  ;*** sbreak here!
	pha          ; nonsens
	pla
	rts
	
COPA_ATTIC_DEST = $8109000		; Destination of the byte stream to check

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new New report, not classified yet
Projects
None yet
Development

No branches or pull requests

2 participants