My Arduino-Based 6502 Simulation/Emulation...thing?

[BigEd]

Right - getting commonality is a big step forward.
One of my bugs was setting the flags for TXS, because it's an exception to the T commands.
(see http://www.visual6502.org/JSSim/expert. ... a&steps=24)

[halkun]

Well, that was fun.. I ported what I could over... and now, it's sadly more broken then before. Because I've changed so much, I'm attaching the new C++ code the core uses. I'm also posting the the current cc65 makefile and active dependencies for the Monitor.

Just to let you know, this is the output I get from the help screen now...

Code: Select all

65C02 Monitor v5.1.1 (12-02-12) Ready
By Lee Davison and Joshua Walker
(Press ? for help)
Current commands are :
Syntax = {} required, [] optional, HHHH hex address, DD hex data

[HHHH][ HHHH]{Return} - Hex dMPJSRLDALDXLDYLSRNOPORAPHAPHPPHXPHYPLAPLPPLXPLYROLRORRTIRTSSBCSECSEDSEISTASTXSTYSTZTAXTAYTRBTSBTSXTXATXSTYAWAISTPBBRBBSRMBSMB.DB.DW.DS???
Current commands are :
Syntax = {} required, [] optional, HHHH hex address, DD hex data

[HHHH][ HHHH]{Return} - Hex dMPJSRLDALDXLDYLSRNOPORAPHAPHPPHXPHYPLAPLPPLXPLYROLRORRTIRTSSBCSECSEDSEISTASTXSTYSTZTAXTAYTRBTSBTSXTXATXSTYAWAISTPBBRBBSRMBSMB.DB.DW.DS???
Current commands are :
Syntax = {} required, [] optional, HHHH hex address, DD hex data

[HHHH][ HHHH]{Return} - Hex dMPJSRLDALDXLDYLSRNOPORAPHAPHPPHXPHYPLAPLPPLXPLYROLRORRTIRTSSBCSECSEDSEISTASTXSTYSTZTAXTAYTRBTSBTSXTXATXSTYAWAISTPBBRBBSRMBSMB.DB.DW.DS???
Current commands are :
Syntax = {} required, [] optional, HHHH hex address, DD hex data

[HHHH][ HHHH]{Return} - Hex dMPJSRLDALDXLDYLSRNOPORAPHAPHPPHXPHYPLAPLPPLXPLYROLRORRTIRTSSBCSECSEDSEISTASTXSTYSTZTAXTAYTRBTSBTSXTXATXSTYAWAISTPBBRBBSRMBSMB.DB.DW.DS???
Current commands are :
Syntax = {} required, [] optional, HHHH hex address, DD hex data

That loops forever. I'll start stepping though the core after work tomorrow to fix up the opcodes. It's pretty late now.

posted below is my work so far

[halkun]

Nope, I'm stuck again. I'm trying to fix the display error above with the help command.
I've obviously botched up the flags. The reason why I think that's the case is because it was a cute "addition" I added to the code without making sure the other code worked first.

I also don't have a backup if the code that "worked" before I made the changes...

The good news is what's broken is a small bit of code...

Code: Select all

Help_Cmd:       lda   #<HelpTxt         ;  lower byte - Menu of Commands
               sta   AddrPtr           ;
               lda   #>HelpTxt         ;  upper byte
               sta   AddrPtr+1         ;
               bra   Help_Cmd3         ;
Help_Cmd4:      cmp   #$7e              ;  "~"
               beq   Help_Cmd1         ;
               jsr   Output            ;
               bra   Help_Cmd2         ;
Help_Cmd1:      jsr   Print_CR          ;     
Help_Cmd2:      jsr   Inc_AddrPtr       ;    <--- This is where it's breaking
Help_Cmd3:      lda   (AddrPtr)         ;
               bne   Help_Cmd4         ;
               rts                     ;

Inc_AddrPtr:    INC   AddrPtr           ;  increments AddrPtr
               BNE   Inc_addr1         ;
               INC   AddrPtr+1         ;
Inc_addr1:      RTS  

Cool, just two opcodes to tear apart. INC and BNE

The data it's using is here...

Code: Select all

               .byte "JMP"             ;1C
               .byte "JSR"             ;1D
               .byte "LDA"             ;1E
               .byte "LDX"             ;1F
               .byte "LDY"             ;20
               .byte "LSR"             ;21
               .byte "NOP"             ;22
               .byte "ORA"             ;23
               .byte "PHA"             ;24
               .byte "PHP"             ;25
               .byte "PHX"             ;26
               .byte "PHY"             ;27
               .byte "PLA"             ;28
               .byte "PLP"             ;29
               .byte "PLX"             ;2A
               .byte "PLY"             ;2B
               .byte "ROL"             ;2C
               .byte "ROR"             ;2D
               .byte "RTI"             ;2E
               .byte "RTS"             ;2F
               .byte "SBC"             ;30
               .byte "SEC"             ;31
               .byte "SED"             ;32
               .byte "SEI"             ;33
               .byte "STA"             ;34
               .byte "STX"             ;35
               .byte "STY"             ;36
               .byte "STZ"             ;37
               .byte "TAX"             ;38
               .byte "TAY"             ;39
               .byte "TRB"             ;3A
               .byte "TSB"             ;3B
               .byte "TSX"             ;3C
               .byte "TXA"             ;3D
               .byte "TXS"             ;3E
               .byte "TYA"             ;3F
               .byte "WAI"             ;40
               .byte "STP"             ;41
               .byte "BBR"             ;42 4Byte Opcodes
               .byte "BBS"             ;43
               .byte "RMB"             ;44
               .byte "SMB"             ;45
               .byte ".DB"             ;46 define 1 byte for assembler
               .byte ".DW"             ;47 define 1 word for assembler
               .byte ".DS"             ;48 define a string block for assembler
               .byte "???"             ;49 for invalid opcode
;
;
HelpTxt:        .byte "~Current commands are :~"
               .byte "Syntax = {} required, [] optional, HHHH hex address, DD hex data~"
               .byte "~"
               .byte "[HHHH][ HHHH]{Return} - Hex dump address(s)(up to 16 if no address entered)~"
               .byte "[HHHH]{.HHHH}{Return} - Hex dump range of addresses (16 per line)~"
               .byte "[HHHH]{:DD}[ DD]{Return} - Change data bytes~"

What is happening in the code is that when AddPtr is wrapping around, and as opposed to incrementing to the next line, it's pointing WAY up above in another text section. It then reads that all the way down and loops again.

Here's my relevant code for INC ZP

Code: Select all

#define UMASK  0xFF
#define C_FLAG	0b00000001
#define Z_FLAG	0b00000010
#define I_FLAG	0b00000100
#define D_FLAG	0b00001000
#define B_FLAG 	0b00010000
#define X_FLAG	0b00100000
#define V_FLAG	0b01000000
#define N_FLAG	0b10000000

void INC(int addr)
{
	int value;
	value = memReadByte( addr );
	++value;
	memStoreByte( addr, value&UMASK ); //mask off the lower byte
	setNVflags(value);
}

//set zero and negative processor flags based on result
void setNVflags(int val)
{
	if( val ) 
	{regP &= ~Z_FLAG;}
	else 
	{regP |= Z_FLAG;}
	
	if( val & N_FLAG )
	{regP |= N_FLAG;}
	else
	{regP &= ~N_FLAG;}

}

and to be complete, here's BNE

Code: Select all

	case 0xd0:                          // BNE
		offset = popByte();
		if (!zeroSet()) {jumpBranch(offset); }
		break;

which uses this call...

Code: Select all

int zeroSet() { return regP & Z_FLAG;}

now, here's where it gets strange... These all should work, but I can't see what it's doing wrong
Thinking it's the flag tester I replaced it with the old code...

Code: Select all

void setNVflags(int value)
{
		if( value ) regP &= 0xfd; else regP |= 0x02;
		if( value & 0x80 ) regP |= 0x80; else regP &= 0x7f;
}

and it does the same thing.
I'm stuck...

[BigEd]

You need to do the masking before you test the value.

[MichaelM]

This comment is not necessarily helpful for your current problem, but it might help in the future.

The function you are using to set the N and Z flags is named setNVflags() instead of setNZflags(). The BIT instruction sets the N and V flags, so at some future point you may have a conflict, and a lot of code to correct.

[Tor]

halkun wrote:

I also don't have a backup if the code that "worked" before I made the changes...

I keep everything I write these days under version control, specifically 'Git' because the overhead of just versioning something already written is so low. And it allows me to keep adding debug statements and test code to my files and only commit the real changes. It's been invaluable for my emulators (or simulators) for sure - I can always go back to earlier versions and find out where something broke that worked before (something I may not notice until many iterations later). I can even automatically 'bisect' the versions to quickly home in on the spot where it broke.

-Tor

[BigEd]

MichaelM wrote:

This comment is not necessarily helpful for your current problem, but it might help in the future.

The function you are using to set the N and Z flags is named setNVflags() instead of setNZflags(). The BIT instruction sets the N and V flags, so at some future point you may have a conflict, and a lot of code to correct.

Yes, the easy6502 inherits the same naming oddity (probably from the same upstream influence) - it's a trap for the unwary.

[8BIT]

It appears that the Addr+1 is getting decremented instead of incremented.

You may want to add some dumps inside your code to your LCD to show the pre/post values:

Code: Select all

void INC(int addr)
{
int value;
   value = memReadByte( addr );
   dmplcd(value); /* substitute your lcd dump code here */
   ++value;
   memStoreByte( addr, value&UMASK ); //mask off the lower byte
   setNVflags(value);
   value = memReadByte( addr );
   dmplcd(value); /* substitute your lcd dump code here */
}

Another thought might be to define value as a char instead of int.

If INC works well, then check your lda (AddrPtr) to be sure the indirect is working right.
Have it dump the target address to the LCD to confirm.

Daryl

[whartung]

For the record, here's my INC:

Code: Select all

    private int setFlagsNZ(int i) {
        status &= ~(ZERO_MASK + NEGATIVE_MASK);
        if (i == 0) {
            status |= ZERO_MASK;
        }
        if ((i & NEGATIVE_MASK) != 0) {
            status |= NEGATIVE_MASK;
        }
        return i;
    }

    public void doInc(int addr, int value) {
        int result = fetchByte(addr);
        result = result + value;
        if (result == -1) {
            result = 255;
        }
        if (result == 256) {
            result = 0;
        }
        setFlagsNZ(result);
        putByte(addr, result);
    }

    public void INC(int addr) {
        doInc(addr, 1);
    }

    public void DEC(int addr) {
        doInc(addr, -1);
    }

[halkun]

When doing bit wise operations on chars, don't they cast to ints in the process?

Oh, and BTW, you guys rock

[BitWise]

halkun wrote:

When doing bit wise operations on chars, don't they cast to ints in the process?

Oh, and BTW, you guys rock

Most micro-controller C compilers avoid integer promotion where possible but when in doubt peek at the generated code.

[halkun]

progress... kind of

Code: Select all

65C02 Monitor v5.1.1 (12-02-12) Ready
By Lee Davison and Joshua Walker
(Press ? for help)
>R
 PC=CD30  A=11  X=00  Y=BF  S=6C  P=FF (NVRBDIZC)=11111111    <----huh?

>E800L
E800-  L    4C         INX                                 <----- Nope!
E801-  LiL  4C E9 4C   JMP  $4CE9
E804-  .    88         INX
E805-  h    E8         INX
E806-  L9h  4C B9 E8   JMP  $E8B9
E809-  L6   4C B6      LDX  $B6,Y
E80B-  hL1  E8 4C B1   JMP  $B14C
E80E-  hL"  E8 4C A2   JMP  $A24C
E811-  hL.  E8 4C 99   JMP  $994C
E814-  hL.  E8 4C 95   JMP  $954C
E817-  hL<  E8 4C 3C   JMP  $3C4C
E81A-  iLB  E9 4C 42   JMP  $424C
E81D-  iL4  E9 4C 34   JMP  $344C
E820-  iL.  E9 4C 2E   JMP  $2E4C
E823-  iL8  E9 4C 38   JMP  $384C
E826-  iLA  E9 4C C1   JMP  $C14C
E829-  hLE  E8 4C C5   JMP  $C54C
E82C-  h P  E8 20 50   JSR  $5020
E82F-  C=   43 3D 20   AND  $203D,X
E832-   A   20 41      EOR  ($41,X)
>

Fixed the flag issue, but bugs remain.
Looks like I have a bug in ROR (for the flag printing) and something is going funny with the list dump (4C is a JMP instruction, not an INX), however it sorts itself out later.
I don't think I'm setting carry right on the shifters.

[frikosal]

Hi !
I'm new in this forum; actually I have just registered to be able to post here.
I'm becoming more and more interested about this project, I was wondering how much memory is needed by the emulator itself.
Would it be possible to run it with an Arduino Mega, without the memory expansion ?
My idea would be to leave only the minimum memory for the 6502 space, if I'm not wrong (it's been a long time since I used a 6502 for the last time), with 1kb it should be enough.
Thanks !

[Simon]

Old computers with IDE drives are a good source of ribbon cable. I deliberately made the expansion port on my little Orwell machine with a 40 pin IDE type connector just so I can reuse old PC IDE cables on it.

I used to have great fun with the special characters on those little LCDs. Doing small running men animations (think Loderunner) and the like.

As an extra goal make a little stand alone computer that can be used for something. I am using mine to review old 80s computer books.

Cool little project you've got there!

Simon

[BigDumbDinosaur]

Simon wrote:

Old computers with IDE drives are a good source of ribbon cable. I deliberately made the expansion port on my little Orwell machine with a 40 pin IDE type connector just so I can reuse old PC IDE cables on it.

Simon, if you weren't so far away I'd ship you all of the IDE cables in our inventory. Each year between Christmas and New Year, we go through the old inventory and decided what should stay and what shouldn't. Over the years, we have collected literally hundreds of IDE cables, most of which were shipped with motherboards used in builds where no IDE hardware was used. I've decided that when we start the annual purge on Thursday these cables are going to the electronics recycler so they can grind them up and turn them into Apple iPhones.