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.

Plus SEI and CLI differences.

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.

_________________
How should I know what I think, until I hear what I've said.

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

_________________
Please visit my website -> https://sbc.rictor.org/

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.

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

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

_________________
Please visit my website -> https://sbc.rictor.org/

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

_________________
Please visit my website -> https://sbc.rictor.org/

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:
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.
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.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

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

_________________
Please visit my website -> https://sbc.rictor.org/

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

_________________
Please visit my website -> https://sbc.rictor.org/

Nice tradeoff of space for time!

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

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

(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.)

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

_________________
Please visit my website -> https://sbc.rictor.org/