AVR-based 6502 Emulator

[clockpulse]

8BIT wrote:

Also, I wish you could access Flash with more than just the Z register pair.

That would be helpful. I did see some references to RAMPX and RAMPY somewhere, not sure if there is an AVR that would have those instructions.

8BIT wrote:

Yes, the instruction set is similar. It is interesting that the C flag is handled opposite for subtraction in the AVR.

Plus SEI and CLI differences.

[mkl0815]

How stable is the ATmega1284 running at 24MHz? According to AVR site, the maximum operation frequency is 20MHz. So you overclocked it with 20%. That's a lot, i think.

[8BIT]

mkl0815 wrote:

How stable is the ATmega1284 running at 24MHz? According to AVR site, the maximum operation frequency is 20MHz. So you overclocked it with 20%. That's a lot, i think.

It has been running without any trouble using 24MHz. I am using a TTL Oscillator vs. a crystal and I do not have any IO connected. I did experiment with an ENC24C50 Ethernet board using an SPI interface and it also ran well at 24MHz.

However, it would still provide about 1.5MHz emulated speed using a 20MHz clock so if it ever became a problem, I'll have it covered.

Daryl

[clockpulse]

So far I haven't seen any problems running a 1284p at 24Mhz.
I saw a video project where someone was using 25Mhz with that device and other users claiming even higher frequencies.

Also, the UART frequency works out with a much lower error for a 24Mhz clock versus 20Mhz when using a 115,200 baud rate.

[8BIT]

I have updated my website with the latest version of the Emulator. Unless any bugs are reported, this will be my final update. I have added FigForth and Peter Jennings' Micro Chess to the SBC-2 OS image.

http://sbc.rictor.org/avr65c02.html

Enjoy!

Daryl

[8BIT]

For today (and maybe tomorrow), I have my AVR65C02 Emulator connected to an ENC28J60 Ethernet module and have my Remote Access Web Server back online. You can view it here:

{dead link removed}

I created a few sample labels but I do not have the inputs actually connected. They are just floating.

I will put my ATMega128 Web Server back up after I take this one down.

Daryl

[BigEd]

Excellent! Refreshing the pages every 10 seconds is likely to increase the load - prepare for a traffic spike! (We've just mentioned this project in a post on gplus)

Cheers
Ed

[8BIT]

BigEd wrote:

Excellent! Refreshing the pages every 10 seconds is likely to increase the load - prepare for a traffic spike! (We've just mentioned this project in a post on gplus)

Cheers
Ed

[Klaus2m5]

Good to see, that you have improved your project in speed as well as compatiblity. Very nice!

Still I have some recommendations. Don't put the ATMEGA1284 manual with the code. Since I was following your project from the beginning, I have downloaded the manual now for the 4th time and I had it already. It would be nice to have it as a separate download or just point to the download on Atmel's website.

You are doing a "jmp MAIN" at the end of every instruction. If you still have lots of flash space available, adding the MAIN code snippet as a macro to the end of every instruction would save 3 AVR cycles per instruction. If space is limited you could do it at least for the most used instructions.

The code itself could also be improved:

Code: Select all

Main:

	sbic	gpior0, 0	; if IRQ triggered
	rcall	cpu_irq     ; execute it now

cpu_exec:
	movw	ZL, XL		;
	adiw	XL, 1		;
	cp		zh, mmap	; IO page
	breq	IO
	brcs	RAM
ROM:
	lpm		zl, Z
	rjmp	fetch
IO:
	ldi		zl, 0xEA	;nop in IO area
	rjmp	fetch
RAM:
	inc		zh
	ld		zl, Z
fetch:
	ldi		zh, high(opctbl)
	lsl		zl
	adc		zh, zero	; pointer to opcode jump
	ijmp				; call opc code

The "breq IO" can be ommited and you could put 256 * 0xEA in front of the ROM image. This is true not only for the opcode fetches, but also for any other instruction stream fetch, as those should never read from IO-space. The NOP instruction (as it is not doing anything else) in turn could check for X-1 pointing to IO and call an exception. Saves 1 cycle.

Instead of the "rjmp fetch" in the ROM:-part you could repeat the actual code in the fetch:-part saving another 2 cycles for ROM fetches.

Code: Select all

.macro      op_decode
	sbic	gpior0, 0	; if IRQ triggered
	rcall	cpu_irq     ; execute it now
	.ifndef cpu_exec
		.equ cpu_exec = pc
	.endif
	movw	ZL, XL		;
	adiw	XL, 1		;
	cp		zh, mmap	; IO page
	brcs	RAM
ROM:
	lpm		zl, Z
	ldi		zh, high(opctbl)
	lsl		zl
	adc		zh, zero	; pointer to opcode jump
	ijmp				; call opc code
RAM:
	inc		zh
	ld		zl, Z
	ldi		zh, high(opctbl)
	lsl		zl
	adc		zh, zero	; pointer to opcode jump
	ijmp				; call opc code
.endmacro

Then replace all "jmp MAIN" with op_decode.

Oh, one more thing. Your invalid opcodes are all implemented as 1 byte NOPs but the real thing has some implemented as 2 or 3 byte NOPs. You bet, that I will test that in the upcomming 65C02 version of my functional test.

[8BIT]

I appreciate the recommendations Klaus!

I have focused at that section of code for some time and was thinking of I could just speed this up a little more I could probably break the 2MHz speed barrier. I will give those changes a try.

Also, I will look forward to your 65C02 test suite. Fixing the NOP's will be easy.

thanks!

Daryl

[8BIT]

Hi Klaus,

I made the changes you suggested. I ran out of space in the lower Flash so I moved the Emulator above the Emulated ROM space. My simplistic speed test now reports 2.08MHz

I need to update the bootloader to account for the Emulator move, but that should be easy. The backup BIN file will become larger to cover the Tables, ROM image, and Emulator but that is only a minor impairment.

I also took the Datasheet out of the source archive.

Once I fix the bootloader, I'll post the updated code.

Thanks again Klaus for the suggestions!

Daryl

[BigEd]

Nice tradeoff of space for time!

[Klaus2m5]

Hi Darryl,

you probably noticed by now, that I missed the label cpu_irq getting out of reach. Replacing the rcall with a call costs +1 AVR cycle, as the skip simply reads over the now double word instruction.

The solution could be calling a local label inside the macro and then jmp cpu_irq. 3 more cycles for an interrupt, 1 less cycle again for every instruction.

Anyway, good to see that I could be of help for your project!

cheers, Klaus

[BigEd]

(I tried to do the trick of replicating the dispatch code at the tail of each instruction's handler in my a6502 project, but I couldn't get the ARM's computed-goto instruction to cooperate.)

[8BIT]

Klaus2m5 wrote:

Hi Darryl,

You probably noticed by now, that I missed the label cpu_irq getting out of reach. Replacing the rcall with a call costs +1 AVR cycle, as the skip simply reads over the now double word instruction.

The solution could be calling a local label inside the macro and then jmp cpu_irq. 3 more cycles for an interrupt, 1 less cycle again for every instruction.

Anyway, good to see that I could be of help for your project!

cheers, Klaus

Yes, and adding the local label worked well. I also updated the unused opcodes to use the proper # of NOP bytes, per the WDC datasheet.

I am now up to 2.1MHz

Still working on the boot loader update. I now have to increment rampz in the middle of the file transfer.

thanks again!

Daryl