6502 emulator and VICE bug

hydrophilic
Global Moderator

Posts: 794

6502 emulator and VICE bug Feb 2, 2021 6:29:22 GMT

Quote

Post by hydrophilic on Feb 2, 2021 6:29:22 GMT

Quick thought and maybe you guys have some opinions, but...

There is a series of 34 videos on YouTube about creating a 6502 emulator in C++ from scratch... these videos may be informative for anyone interested in writing an emulator in general (or as an introduction to 6502?). As a seasoned 6502 programmer I was constantly amazed at this guy's lack of knowledge about the CPU... but through perseverance he eventually developed a fair emulator. You can view the first of the series here: www.youtube.com/watch?v=qJgsuQoy9bc

More importantly, one of the things I don't think he ever got right was the RES(et) functionality of his emulator. As I recall from experimenting with a HARDWARE emulation of the 6502, available for free at Visual 6502, the NMI, IRQ, and RES all work (essentially) the same. They also work (essentially) the same as the BRK instruction.

Which got me curious and I started playing around with VICE. It seems VICE has a core bug: RES (reset). I mean this is, LITERALLY, the first the thing the CPU ever does when it powers on (or when it gets reset), and yet somehow the VICE team, despite all their otherwise amazing cycle accuracy, seems to have FAILED!

Three important things that most experienced 6502 programmers know:

JSR pushes the PC-1 on the stack
IRQ / NMI push the PC on the stack

3. After pushing stuff, the S (stack) register points 1 byte lower

The minus one with JSR is (indirectly) related to the reading of the opcode and target address from program memory. IRQ / NMI do not need to read anything from program memory so it should be only a mild surprise the true (not minus one) address is saved on the stack.

Also, IRQ, NMI -- and even BRK -- set the I-flag (interrupt disable).

However, playing around with VICE (by changing the ROM reset vector) I discovered some things that SEEM wrong:

During RES, PC-1 is pushed to the stack (contrary to IRQ and NMI)
After RES, the stack pointer points to the last byte written (not 1 byte lower like every other stack-pushing function)
After RES, the I flag is not set (contrary to IRQ, NMI, and BRK)

Comments everybody!!!

Unfortunately both the C64 and C128 (as far as I can tell) invoke SOME kind of ROM (internal or cartridge) during reset which means I can't directly test this behavior (since I don't have an [[E]EP]ROM programmer).

Any thoughts? [Sorry if my quick thought became an essay!]

I'm kupo for Kupo Nuts!
∇ • hydrophilic ≠ 0

bjonte
Plus/4 User

Posts: 406

6502 emulator and VICE bug Feb 2, 2021 11:35:37 GMT via Tapatalk

Quote

Post by bjonte on Feb 2, 2021 11:35:37 GMT

Interesting stuff! I didn’t know about the reset details.

I’m not surprised that VICE don’t handle the reset state correctly. It is driven by failing examples and since there’s really no point in reading unused stack locations after a reset that will never break anything but faulty programs. The interrupt flag is also reset of course.

However, if you have access to a 1541U2 or Easyflash you could make some custom ROM images that shows the correct behavior on real hardware and fails in VICE. You can perhaps get by with a cartridge image also, depending on what the ROM does before the cartridge code is executed.

willymanilly
Global Moderator

Posts: 219

6502 emulator and VICE bug Feb 2, 2021 21:43:39 GMT

Quote

Post by willymanilly on Feb 2, 2021 21:43:39 GMT

Thanks for the share. I watch part of the video and what I saw of how the RESET vector was shown to work is mostly incorrect. As we all know instructions don't start executing at $FFFC, instead $FFFC/$FFFD contains the location in memory where the first instruction is fetched.

As far as I'm aware from research I've done to date is the RESET routine exactly the same cycles as a BRK statement except RW is not set to write during the stack cycles so nothing should be written to the stack during reset. The stack pointer is reset to 0 so it should have a value of $FD by the end of the RESET cycles. This has also been discussed at atariage.com/forums/topic/261488-reset-sp/ which includes a bin file (cartridge for Atari 2600) that does similar to what you suggested to test with the C64.

For anyone interested Z64K uses the same code to handle BRK, Interrupts and RESET. Attached is the code (slightly modified) that Z64K uses. I've exclude code (...) not directly related to the BRK/Interrrupt/RESET cycles. The function updateBus() handles the actual reading/writing to memory.

public void clockCycle(){
        switch(cpuState){
		....
		case FETCH:fetchInstruction();break;
 		case INTERRUPT:cpuState =INTERRUPT_1;P&=~0x10;break;
		case BRK:PC++;
		case INTERRUPT_1:RW=false;
		case RESET:DL=(PC>>8)&0xff;pushStack();cpuState =BRK_1;break;
		case BRK_1:DL=PC&0xff;pushStack();cpuState =BRK_2;break;
		case BRK_2:DL=P;pushStack();if(NMI.trigger){NMI.trigger=false;irqVector &=0xfffa;}cpuState =BRK_3;P|=0x10;break;
		case BRK_3:AB=irqVector;irqVector |=0x6;cpuState =BRK_4;fetchType=FETCH;RW=true;break;
		case BRK_4:P|=0x04;IRQ.trigger=IRQ.allowTrigger=false;SB=DL;AB=(AB&0xff00)|((AB+1)&0xff);cpuState=PC_FETCH;break;
		case PC_FETCH:PC=(DL<<8)|SB;AB=PC;cpuState=fetchType;break;
		....
	}
	 updateBus();
	...
}

private void pushStack(){AB=0x100|SP--;SP&=0xff;}

public void reset(){
        SP=0;
        irqVector=0xfffc;
        cpuState =RESET;
        IRQ.reset();
        NMI.reset();
        stopMask=0;
        RW=RDY=true;
}

Last Edit: Feb 2, 2021 21:54:23 GMT by willymanilly

wsoft Vic 20 User Posts: 131	6502 emulator and VICE bug Feb 5, 2021 0:01:27 GMT Quote Select Post Deselect Post Link to Post Member Give Gift Back to Top Post by wsoft on Feb 5, 2021 0:01:27 GMT So this is where the old tech has gone? You guys sure sound sharp to me, everything was chinese.

oziphantom
C-64 User

Posts: 198

6502 emulator and VICE bug Feb 6, 2021 14:36:46 GMT

Quote

Post by oziphantom on Feb 6, 2021 14:36:46 GMT

You may be able to test the stack with the Monitor reset on a 128. Hold Ctrl while you press reset. It might still trash the stack but the idea of it is so you can enter and debug code, to that end I would expect it to preserve the stack for you to look at, to work out the last JSR it took when you hit reset.

wsoft
Vic 20 User

Posts: 131

6502 emulator and VICE bug Feb 15, 2021 20:46:53 GMT

Quote

Post by wsoft on Feb 15, 2021 20:46:53 GMT

If something was nefariously affecting the stack upon a reset then my own program would be the last one to be affected by this as it sets the stack itself upon every boot to $FA or something. The rest went ZIP, right over. Helps I guess if you're in your prime years. You guys are sharp, stay away from weed [edit: or those who smoke more for mankind like I do]

Last Edit: Feb 15, 2021 21:49:10 GMT by wsoft

tokra Global Moderator Posts: 181	6502 emulator and VICE bug Feb 16, 2021 14:27:44 GMT Quote Select Post Deselect Post Link to Post Member Give Gift Back to Top Post by tokra on Feb 16, 2021 14:27:44 GMT Off-topic deleted. Political discussion never ends well on these forums, best to keep the topic limited to the C128.

oziphantom C-64 User Posts: 198	6502 emulator and VICE bug Feb 17, 2021 8:06:39 GMT willymanilly likes this Quote Select Post Deselect Post Link to Post Member Give Gift Back to Top Post by oziphantom on Feb 17, 2021 8:06:39 GMT At the end of this page, there is commentary on the RESET stack masking www.visual6502.org/wiki/index.php?title=6502_BRK_and_B_bit so the 6502 won't write to the stack on RESET.

Commodore 128

6502 emulator and VICE bug

Post by hydrophilic on Feb 2, 2021 6:29:22 GMT

Post by bjonte on Feb 2, 2021 11:35:37 GMT

Post by willymanilly on Feb 2, 2021 21:43:39 GMT

Post by wsoft on Feb 5, 2021 0:01:27 GMT

Post by oziphantom on Feb 6, 2021 14:36:46 GMT

Post by wsoft on Feb 15, 2021 20:46:53 GMT

Post by tokra on Feb 16, 2021 14:27:44 GMT

Post by oziphantom on Feb 17, 2021 8:06:39 GMT

Quick Reply