6502.org

Posted: **Thu Feb 05, 2026 6:23 am**

barrym95838 wrote:

fachat wrote:

You may know this behaviour from machine language monitors on the C64, where it even works upward, but that is without mode bits.... (re: ******) ....

Wasn't scanning 65xx machine code "against the grain" a bit of a crapshoot anyway, even without the M and X bits?

Yes but if you started far enough 'above' chances were actually good that it had synced with the actual instruction flow in time. I don't remember exactly, but my @mon was probably starting to scan 10-16 bytes before the instruction in the top line and it worked quite well.

André

Posted: **Wed Feb 11, 2026 10:05 am**

I'm almost there ...

One thing I noticed is that work area where an MVP or MVN opcode is written to and which is used and executed from various places. I was wondering what that was for?

My plan was/is to move all vars to direct page so I can run the complete code in parallel with different direct page settings. But that self modifying code work area prevents that or at least makes it more difficult.

Thanks
André

Posted: **Wed Feb 11, 2026 12:52 pm**

MVN takes operands inline - the source and destination bank - so it would often, I think, have to be a constructed instruction.

Posted: **Wed Feb 11, 2026 5:25 pm**

BigEd wrote:

MVN takes operands inline - the source and destination bank - so it would often, I think, have to be a constructed instruction.

Correct...I used self-modifying code to set the banks when I wrote the copy and fill functions.

I’ve often wondered why those instructions weren’t designed to use something other than immediate-mode to pick up the banks. Getting the banks from a contiguous pair of direct-page locations would have made more sense and made it much easier to use MVN and MVP in code running from ROM.

Posted: **Wed Feb 11, 2026 6:30 pm**

Yes, getting the banks from direct-page would make it easier to use MVN and MVP, but I perceive a downside.

MVP and MVN work by repeatedly fetching the entire instruction (as shown in Table 5-7 of the '816 datasheet). IOW, fetching the instruction and moving the first byte takes 7 cycles (which is a bit slow... but not surprising, given that it's the first time through). And then -- even after you'd think the pump is primed, so to speak -- there's NOT any speedup on subsequent iterations! The '816 has apparently forgotten what the opcode and the two operands were, and needs to go back and fetch them again.

Ideally it could simply remember that stuff, but remembering is actually pretty complicated, given that an interrupt could occur before the next byte gets moved. Presumably to limit complexity, the designers opted instead to (re-)fetch the instruction, each and every time. With this approach, returning from an interrupt doesn't pose any issues.

Block-move performance would drop if the instruction fetch were to take longer. If the two bank bytes had to be retrieved from direct-page, that'd add two cycles (meaning 9 cycles per byte moved rather than 7).

-- Jeff

Posted: **Mon Feb 16, 2026 9:08 pm**

Hm, another interesting catch: in the disassembly code, after dpycod02 the operand is being read using

Code: Select all

lda operand,y

, while it is written before using

Code: Select all

sta operand,x

.

This is unfortunate as the 65816 only as the ",X" versions using the direct page, but not ",Y" - so the store is happening into direct page (in my memory setup) as the assembler optimizes the opcode, but is being read from absolute as this cannot be optimized into directpage.

Directpage is actually intended as I want to run the monitor potentially in parallel with variables all in directpage and different directpages per "thread".

I'll have to see if I can change that ... seems possibly although X has to be protected as dpyhex is using it (why actually?)

André

Edit: yes, seems to work

Posted: **Mon Feb 16, 2026 9:42 pm**

I wonder if 65816 assemblers should issue a warning whenever they encounter a single byte = directpage address that they can only use with an absolut addressing mode opcode... dp and normal addresses should probably be incompatible...

Posted: **Tue Feb 17, 2026 5:55 am**

fachat wrote:

Hm, another interesting catch: in the disassembly code, after dpycod02 the operand is being read using

Code: Select all

lda operand,y

, while it is written before using

Code: Select all

sta operand,x

...

I’d have to review the code to see what my intention was at that point. I’m usually pretty careful about using DP addressing modes when possible, so it could mean I missed an opportunity, or .X was tied up for some reason at that point in the code.

Posted: **Tue Feb 17, 2026 6:29 am**

fachat wrote:

I wonder if 65816 assemblers should issue a warning whenever they encounter a single byte = directpage address that they can only use with an absolut addressing mode opcode... dp and normal addresses should probably be incompatible...

I suppose such a warning might be worth having. However, intentionally forcing absolute or absolute-long addressing with the 65C816 can often add some flexibility to your code.

For example, I might force absolute addressing so an LDA $00 instruction is assembled as AD 00 00, rather than as A5 00 (it’s done in the Kowalski assembler with the instruction LDA \2$00). With the 65C816, the former machine code causes the fetch to occur from $bb0000, where bb is whatever is in the DB register.

A similar technique also makes it possible to load from the physical direct page when DP is currently pointed elsewhere, as is often the case in many of my library functions when I temporarily point DP to the stack. If DP is loaded with $B8E0 and the MPU executes A5 00, it’s actually executing LDA $00B8E0. If I write LDA \3$00 in the Kowalski assembler, it will generate the machine code AF 00 00 00, which will fetch from physical address $000000—it’s the 24-bit version of LDA $00.

Posted: **Tue Feb 17, 2026 9:42 pm**

I am not sure if there is not an issue with the copy command when doing the reverse copy.

In this code in

Code: Select all

moncpy

, you add the operand to a register to get the end address - but only after setting up the MVN/MVP "workspace" (if I interprete that right) - which on the other and overwrites the operand.

Code: Select all

.0000010 lda facb              ;get bytes to copy       
         pha                   ;protect                 
         jsr lodbnk            ;load banks              
         jsr cprvsup           ;do reverse copy setup       <----------------
         pla                   ;get bytes to copy       
         tax                   ;save a copy             
         clc                                            
         adc operand           ;change target to...          <---------------
         tay                   ;target end              
         txa                   ;recover bytes to copy

together with this as part of cprvsup:

Code: Select all

psup    pha                   ;save banks               
        txa                   ;protect...               
        xba                   ;opcode                   
        sep #m_seta                                     
        ldx !#cpcodeee-cpcode-1                         
                                                        
0000010 lda \3cpcode,x        ;transfer copy code to... 
        sta mcftwork,x        ;to workspace             
        dex                                             
        bpl .0000010

and

Code: Select all

;       copy/fill workspace (overlaps some of the above)... 
;                                                           
mcftwork =faca                 ;start of copy/fill code

and

Code: Select all

faca     =addrb+s_addr         ;primary accumulator           
facax    =faca+s_pfac          ;extended primary accumulator  
facb     =facax+s_pfac         ;secondary accumulator         
facc     =facb+s_sfac          ;tertiary accumulator          
operand  =facc+s_sfac          ;instruction operand

you can see that the memory area behind faca, that includes operand, doubles as MVN/MVP workspace, which in turn is overwritten by the workspace setup before it is used...

(code snippets from your source file, just to be sure I haven't introduced this).

Any idea?
Thanks
André

Posted: **Tue Feb 17, 2026 10:17 pm**

P.S. I found this as I was testing a simple "C 0340 0380 0390"... (or was it T - don't remember and not on the PC anymore). The result was it was copying stuff elsewhere, not where it should be ending up.
André

Posted: **Wed Feb 18, 2026 5:59 am**

After a night of sleep I think the size calculation for the workspace must be wrong in my version. After all it should be only four byte for the MVN/MVP and RTS... will check later

Posted: **Wed Feb 18, 2026 8:57 pm**

Ah yes, that was it. I had commented out the line where X is actually loaded with the length of the workspace *facepalm*

Now I think all commands work, I'll re-check, tag the version and then move over to more deeper changes (pulling the control loop out).

André

Posted: **Wed Feb 18, 2026 10:20 pm**

fachat wrote:

Ah yes, that was it. I had commented out the line where X is actually loaded with the length of the workspace *facepalm*

Now I think all commands work, I'll re-check, tag the version and then move over to more deeper changes (pulling the control loop out).

I’ve been trying to follow along with this but after trying out your t 340 380 390 copy command (c 340 380 390 does a comparison) and getting the expected result, I didn’t know what to think.

Posted: **Thu Feb 19, 2026 11:00 am**

Ah no worries. Thanks for standing in as my proverbial rubber duck

6502.org

Good 65816 monitor?

Re: Good 65816 monitor?

Re: Good 65816 monitor?

Re: Good 65816 monitor?

Re: Good 65816 monitor?

Re: Good 65816 monitor?

Re: Good 65816 monitor?

Re: Good 65816 monitor?

Re: Good 65816 monitor?

Re: Good 65816 monitor?

Re: Good 65816 monitor?

Re: Good 65816 monitor?

Re: Good 65816 monitor?

Re: Good 65816 monitor?

Re: Good 65816 monitor?

Re: Good 65816 monitor?