AVR-based 6502 Emulator

[8BIT]

GARTHWILSON wrote:

Even if slow, this should fill a long-time need for a 6502-based microcontroller where the user's code is onboard. (WDC's 65134 and 65265 microcontrollers are really neat, but onboard ROM is mask-programmed, making them unsuitable for hobbyists. You can have external memory on them only by forfeiting a lot of the I/O pins.) Your onboard A/D converters are definitely a plus! A few questions I was not able to answer from what is written so far are:

1. Are all the AVR's I/O features available to the emulated 6502?
2. Are interrupts supported by the emulated 6502, including for the 4 timer/counters?
3. Does the user's 6502 code get stored in non-volatile memory so it doesn't have to be loaded at every power-up?
4. Is RS-232 the only thing so far that requires the oscillator to be crystal-accurate? I'm wondering if some non-speed-critical applications can get by on an RC oscillator.
5. What price do you think you'll be putting on it?

Thanks. I expect there will be more interest when it appears finished and it's in the webshop and it's clear that development of user applications is easy. I know one thing I myself should eventually look into is videos, since it's too easy for a great thing to go nowhere while those who might have been interested unintentionally shun it because it appears too mysterious.

1- Most IO features are supported. It would be easy to add one if there's one I missed.

2- Interrupts are not fully supported but could be added. I am using timer 1 to provide a 1ms interrupt (IRQ). Other sources could be added. Again, this might drop the performance significantly. If there is enough interest, I will pursue testing it.

3- I have increased the emulated ROM to 48k and the user can load their own bootable code into that area. The 15.75K of RAM does not get pre-loaded or saved. This feature could be added if it is needed.

4- While the AVR can run on an internal oscillator, the max is 8MHz. This would equate to a 250kHz emulated CPU, which is too slow. I do not recommend any system clock below 20MHz. If a speed other than 24MHz is used, the firmware will need adjusting for the RS-232 to work. The 1ms timer is the only other feature that is clock-dependent.

5- I have provided the source and binaries on my website. Th user can program their own if they desire. I will program anyone's device(s) at no cost as long as they cover the postage. My cost for a pre-programmed AVR will be based on the current digikey prices, plus the CA sales tax and shipping - I won't add a mark-up, just want my own expenses covered.

Ask any more questions if you have them!

Daryl

[8BIT]

Fyi, I updated my webpage with more current info.

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

Daryl

[GARTHWILSON]

Quote:

2- Interrupts are not fully supported but could be added. I am using timer 1 to provide a 1ms interrupt (IRQ). Other sources could be added. Again, this might drop the performance significantly. If there is enough interest, I will pursue testing it.

How much would it slow the equivalent clock speed? 15%? Hopefully there could be no more than two extra AVR instructions per emulated 6502 instruction, to test the IRQ\ bit, and if it's true, call the interrupt sequence routine in the AVR code, then the user's ISR determines the cause of the interrupt. Since microcontrollers are used for embedded control, it seems like it would be worth it, even if you left it out of the shortest instructions like CLC and TAX. (I don't know AVR. I'm just envisioning how it might work, and I could be way off.)

Quote:

3- I have increased the emulated ROM to 48k and the user can load their own bootable code into that area. The 15.75K of RAM does not get pre-loaded or saved. This feature could be added if it is needed.

The memory quantities are great. RAM does not need to be non-volatile if the user's code stays in ROM when the power is down.

[8BIT]

I have not really mapped it all out. There are 35 interrupt vectors for the ATMega1284. If you used raw AVR assembly, you could service each source specifically without having to test for what entity caused the interrupt. For the emulator, I would have to create some sort of vector byte to load for each interrupt. Also, in most interrupt routines, the AVR's Interrupt flag would get reset on the reti (RTI). For the emulator, I would have to leave it cleared until the emulated IRQ routine executes it's RTI. Not too hard, but that does put more overhead on the emulator. I cannot imaging it taking too much time. I just didn't think that far forward until now. The 1ms timer would have to scratched but the user could set it up themselves if it was needed.

I'll work up some rough code to test it.

Daryl

[8BIT]

I finally have an update for this project. I re-structured the IO access to allow for direct access to ALL of the AVR's IO space. I kept the minimally-emulated 6551 access and the debugger/single stepper. Interrupts are also enabled but not fully tested.

When one of the AVR's native interrupts occur, it sets a register with an index byte, sets a flag for the emulation engine to see, then exits back to the running emulator (with native interrupts disabled). As soon as the current emulated opcode is finished, the IRQ flag is tested and if active, the IRQ vector is fetched and executed. The AVR's native interrupt's are re-enabled as soon as the emulated Interrupt flag is cleared (active). At least 1 emulated opcode will be executed next. If more than one AVR interrupt was present, or another comes in, the sequence will repeat. The index byte can be read at address $3FFF. Currently, it ranges from $01-$22 but I am planning to change that to $02-$44, using only even-numbered values to facilitate using a jump table.

I know of at least one limitation: For those not familiar with AVR's, there are a few IO features that require two values to be written within a limited number of AVR machine cycles. This of course will not work with emulated code as the timing between the writes will be too long. For instance, writing to onboard EEPROM requires two successive writes to the EECR register within 4 cycles. There are probably a few others that I have not used before too.

I will update this status once I can do more testing.

Daryl

[BigEd]

Quote:

...using only even-numbered values to facilitate using a jump table

Nice idea!

[clockpulse]

8BIT wrote:

I know of at least one limitation: For those not familiar with AVR's, there are a few IO features that require two values to be written within a limited number of AVR machine cycles. This of course will not work with emulated code as the timing between the writes will be too long. For instance, writing to onboard EEPROM requires two successive writes to the EECR register within 4 cycles. There are probably a few others that I have not used before too.

Nice work!

It's only very recently that I have been experimenting with AVR assembly programming.
Hopefully I can answer this question myself someday.

But would it be possible to have a page mode write routine in the AVR code and have the emulated code "call" on it. Maybe write something like 8 or 128 bytes at a time by passing the addresses to the AVR program? I'm assuming the EEPROM read is not as restrictive in the timing. Is there an interrupt routine that needs to be running that might kill the timing?

[8BIT]

Anything is possible. I was thinking that I would just hard-code this by detecting a write of a specific value to an unused IO address. It needs to be simple (i.e. quick) yet not prone to false writes. I have not completed any more work on this project since my last post however. This started out as a "let me throw this together and see what happens" test. I will work on it more when I have the time. Have fun with the AVR's!!

Daryl

[clockpulse]

8BIT wrote:

Anything is possible. I was thinking that I would just hard-code this by detecting a write of a specific value to an unused IO address. It needs to be simple (i.e. quick) yet not prone to false writes. I have not completed any more work on this project since my last post however. This started out as a "let me through this together and see what happens" test. I will work on it more when I have the time. Have fun with the AVR's!!

Daryl

Thanks.
Yes, time is the key. I'm fairly new to CPLD programming as well so I'm trying to get the time to do both.

[8BIT]

After many months on the shelf, I have spent some time updated my AVR6502 project. Here's where it stands today:

- Full WDC 65C02 opcode set supported: BBRx, BBSx, RBMx, SMBx, WAI, and STP included
- BCD math supported
- Full access to the AVR IO registers
- AVR native interrupts supported through the emulated /IRQ - an IRQ vector can be loaded (read from $3F00) to see what caused the interrupt. This vector value ranges from $02 to $44 using even numbers only so a fast jump table can be used. $00 will mean no native interrupt occurred.
- Bootloader that allows the user to download their own ROM images and even update the emulator using a standard serial terminal and XMODEM/CRC file transfer. The Emulator will auto-start after ~15 seconds if no bootloader menu option is selected.

Current Memory Map:
- RAM is $0000-$3EFF (15.75k)
- ROM is $4000-$FFFF (48k)
- AVR IO located at $3F20-$3FFF
- IRQ vector read from $3F00 (mirrored $3F01-$3F1F)
- Onboard 4k of EEPROM can be read using EEPROM access registers in the AV IO space. To Write EEPROM, set the AVR IO EEPROM access registers, then set AVR IO Register GPIOR1 to $5A, followed by writing any value to $3F00 (mirrored at $3F01-$3F1F). Be sure to write GPIOR1 to a value other than $5A to prevent accidental writes when done.

Current emulated speed is near 1.9MHz, up from 1.3MHz after much optimization. Again, this will vary as access to ROM, RAM, ZP RAM, and IO take different times to complete. I am calculating speed using a mixture of ZP, absolute addressing, and IO access while timing the USART output at 4800 baud. I take the # of 65C02 cycles used to run the loops between writes and derive the emulated speed. I tested this using my SBC4 with several different oscillators and the results were pretty accurate.

I removed the minimally-emulated 6551 port and the diagnostic modes (single step and hex dump) - having direct AVR IO access and IRQ's made these too hard to support any longer.

I may look into supporting /NMI using a dedicated IO port pin, but for now its just emulated but does not have an actual trigger.

Finally, I ran Klaus's excellent 6502 test suite and it passed all the tests, after a few emulator bug fixes.

Still to do:

Experiment with AVR Interrupts to be sure they are working as designed/desired.

Verify EEPROM writes and test write timing for any problems

Update the documentation and include some sample code for various IO applications

cheers!

Daryl

[BigEd]

So the 6502 code can update its ROM, or use some parts of ROM for non-volatile variables? Very nice!

I see you're using a 40-pin part, which delivers a ~2MHz 6502 system with lots of I/O.

Is there an AVR micro in a smaller package which still fits your emulator with enough resources to do something useful as a 6502? (To put it another way, how much EEPROM and RAM are needed by the emulator?)

[8BIT]

BigEd wrote:

So the 6502 code can update its ROM, or use some parts of ROM for non-volatile variables? Very nice!

I see you're using a 40-pin part, which delivers a ~2MHz 6502 system with lots of I/O.

Is there an AVR micro in a smaller package which still fits your emulator with enough resources to do something useful as a 6502? (To put it another way, how much EEPROM and RAM are needed by the emulator?)

Hi Ed,

The 6502 code cannot modify the emulated ROM, which is stored in the AVR's flash memory. When the AVR is powered up or reset, the bootloader (AVR code) will prompt you to upload a new ROM image or start the Emulator. Once the emulator is running, the user cannot change the flash contents until the next power/reset cycle. Adding this feature is technically possible, but would require more decoding of the IO space and bootloader modifications.

The 4k of EEPROM on the ATMega1284P is uncommitted and can be used by the user for NV storage.

My Emulator uses a lot of flat code for speed sake, coming it at about 14k bytes. The bootloader uses <2k bytes.

An ATMega328P has 32k bytes of flash (would allow for ~16K of user ROM) and 768 bytes of user SRAM (256 bytes reserved for the AVR stack) and comes in a 28 pin DIP or 32 pin TQFP. This would most likely work for smaller applications, although the bootloader will need to be modified to support flash updates. This could be a future goal.

I hope this help explain things better.

Daryl

[BigEd]

Thanks!

[clockpulse]

8BIT wrote:

After many months on the shelf, I have spent some time updated my AVR6502 project. Here's where it stands today:

- Full WDC 65C02 opcode set supported: BBRx, BBSx, RBMx, SMBx, WAI, and STP included
- BCD math supported
- Full access to the AVR IO registers
- AVR native interrupts supported through the emulated /IRQ - an IRQ vector can be loaded (read from $3F00) to see what caused the interrupt. This vector value ranges from $02 to $44 using even numbers only so a fast jump table can be used. $00 will mean no native interrupt occurred.
- Bootloader that allows the user to download their own ROM images and even update the emulator using a standard serial terminal and XMODEM/CRC file transfer. The Emulator will auto-start after ~15 seconds if no bootloader menu option is selected.

Congrats, very nice update!
I fired up your last version and it runs very good.

Two months ago I didn't know anything about AVR assembly programming.
But I think you said in the past that it was very similar to 6502, you're right because it doesn't take very long to figure things out.

[8BIT]

Yes, the instruction set is similar. It is interesting that the C flag is handled opposite for subtraction in the AVR. Also, I wish you could access Flash with more than just the Z register pair. I do like having all the peripherals built into the chip.

Once I get the to-do list completed, I'll post the update project files on my website.

Daryl