Windfall:

Take a look at the Mode[2:0] outputs of the M65C02 core. It is generated by the M65C02_Decoder_ROM, and it indicates the instruction mode. Two mode values that might be of interest to you are: 7 - BRK and 6 - Invalid Instruction. Also of interest might be the RMW signal.

A zero detector on the IR will also indicate a BRK, but Mode[2:0] is simulataneously asserted with the loading of the IR, and comes from one of the two microprogram ROMs. Thus, is narrower and at least one logic level less than a separate IR decoder. I had forgotten about this field in the Decoder when we were discussing setting up a vectored BRK capability. Just ran across it in the core testbench as I was planning my approach to verifying my new core, which uses a new, registered address generator.

_________________
Michael A.

Thanks, Michael, I'll have a look. I had not yet looked at plugging into BRK. IRQ and NMI were far more important and seem to work fine. As is the rest of your core, by the looks of it, thanks (although the code I run through it is extensive, it's by no means a test suite ... ).

There's some additional documentation on the Appendix B program here:

http://6502org.wikidot.com/errata-other-decmode

dclxvi:

Thanks very much for the pointer. After reading through Bruce Clark's code, kinda of figured the changes indicated in the referenced article were necessary. I did run across that very same article earlier as I was perusing Andre Fachat's web page on this site. Very interesting collection of information, and he points to the page you refer me to.

Do appreciate the pointer though. There is so much to read and digest on this site that it is difficult to find the needed information without some pointers from members like you.

_________________
Michael A.

All:

I've noticed that there have been 16 downloads of the MAM65C02.zip file I attached in a previous post. Thanks to forum members, Windfall in particular, some errors (bugs) were identified in that attachment. The errors have been corrected, and with the help of BigEd, I established a public repository on GitHub to which all corrections have been posted.

Therefore, to those who have downloaded the MAM65C02 core from the attachment, please go to the repository linked to above and get the updated sources. I've added additional files and READMEs to the repository that may be of general interest. I've also updated the ALU and BCD function testbenches to support testing of the posted sources.

_________________
Michael A.

It's worth noting that GitHub offers a zip file to download, so you don't even need to be a git user to get the latest source.

(Michael: I don't know if the safer tactic is for you to update or to remove that earlier attachment, but thanks for the notification in any case!)

Michael, I tried making a symbol of your cpu from all of your files on Github in order to fit it to the XC2S200 Spartan 2 for the 6502 softcore comparison thread using ISE10.1.
It looks like you have the accumulator and all the registers and many more internal signals going off of the CPU. Is this done for testing purposes? Should I wait to compare your core if this is the case? No rush or anything, I just need to know whether or not to procede.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Windfall:

As we discussed in an earlier post, it is just my practice to bring all interesting signals out on the port list. It makes it easier to test each module using ISE. For your purposes, I think you can safely proceed with a small wrapper of your design that simply instantiates the core module, but only declares the IO ports that you want to bring out of the FPGA: RnW (IO_Op[1]), Ack, AO, DO, DI, nIRQ, and nNMI.

At the moment, I am working on a simplification of the core that includes a modification of the core's address generator and internal multiplexing scheme. Unfortunately, I am now in the middle of preparing for a design review and system demonstration, so I will not have much free time for the next 4-6 weeks. I have run into several obstacles in the development of the microcode for the new core. I am trying to avoid some of the issues with its implementation that you suggested early on, so it is taking more time than expected. But I am working on the core whenever I have a free moment.

Just as an aside. The Spartan II family has been the mainstay of all my commercial product designs. I have developed several products based on the XC2S15, XC2S30, and XC2S150 for my company and for others. It has been a fantastic FPGA family to work with since its I/O is 5V tolerant.

Unfortunately, Xilinx issued and recalled a Product Discontinuation Notice for the entire Spartan II family in CY2011. The recall of the notice is only a temporary reprieve, and a new and final notice will most likely be given in mid-2013. TSMC and Xilinx entered into a production agreement that has TSMC agreeing to a two year extension of the Spartan II production line. That agreement was very expensive for Xilinx, and neither party is likely to extend it again.

So it follows that I am also committed to the redesign all of my company's products based on the Spartan II FPGA family. I will be transitioning all of our products to the Spartan 3AN family for the low end FPGAs and to the Spartan 6 for the high end FPGAs. Several of our products are based on two custom 5V ASICs, so I will have to include the relevant level translators because all of the newer low-cost FPGAs are not 5V tolerant. That is certainly a bummer for me, and always results in a more expensive solution. It does appear that with our current product volumes, we will be able to get an XC3S50AN FPGA for less than half of the price of the XC2S30 and the XCF01 configuration SEEPROM combination.

Therefore, before targeting any Spartan II FPGA for any commercial products, I recommend contacting your local Xilinx representative or distributor to get a better idea on how the Spartan II discontinuation may affect your market.

_________________
Michael A.

EEyE:

My last post should have been directed to you. Sorry about that. Must be too much staring at a computer screen that I didn't take note of your call sign.

_________________
Michael A.

No problem... Time to gobble up some Spartan II's I think, never know when you may need one. The ones in the 100-pin and 144-pin QFP are the most appealing, although when I was fitting 6502 cores, some of the first ones I tested only fit in the largest Spartan II. I never did wind up developing any hardware with the Spartan 2.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Yeah. We're going to do that in the short term for risk mitigation. It really is a very nice family for all of the work I've done with: ISA, PC/104, industrial automation interfaces. It's 5V tolerance sure made life easy.

_________________
Michael A.

Allright. No hurry. Just playing around, using my own 'bolt on's. It's all running at 50 MHz now, with the internal FPGA RAM.

I don't use Xilinx, I use Altera. They're in the same boat though. Hard to get chips with 5V operation or tolerance these days ...

All:

I finally got the microprogram ROM generator tool that I had created and used in the generation of the MAM65C02 processor core microprograms in a form suitable for public release. An executable (in a .zip) has been placed in the GitHub repository. I extended the README in that subdirectory with usage and documentation pertaining to the tool: SMRTool.exe (Simple Microprogram ROM Tool).

Unfortunately for some of you it will raise a bad taste in your mouth since it is C# application, and it will require version 4 of the .NET framework and Windows to run. However, since that is predominant development environment that I have to deal with, that is the only environment that the tool currently supports.

_________________
Michael A.

Anyone:

I am trying to wrap up my 65C02 FPGA core, and would like confirmation from someone more familiar with the detailed behaviour of the 65C02 on a couple of addressing modes.

Zero Page Pre-Indexed or Zero Page Post Indexed: zp,X or zp,Y

For these two addressing modes, the carry out of the least significant address is ignored so that the resulting address is modulo 256, i.e. in page 0.

Zero Page Pre-Indexed Indirect: (zp,X)

For this addressing mode, pre-indexing sums zp and X modulo 256, and then two consecutive locations are fetched as the address of the data. If [zp+X % 256] is $00FF, does the high byte of the indirect address come from location $0100 or from $0000.

Zero Page Post-Indexed Indirect: (zp),Y

Base address is two consecutive addresses determined by the zp address in the instruction. The issue is the behavior when the lower byte of the base address is at zero page address $00FF. Does the first byte come from $00FF, and the second byte from $0100, or from $0000?

The post-indexing operation is a 16-bit operation, but if a carry out of the low byte occurs, then the upper byte is adjusted at a penalty of an additional clock cycle.

_________________
Michael A.

Certainly for the NMOS 6502, the addresses within zero page wrap for both those cases. I'd be very surprised if the C02 or 816 did any differently.
http://www.visual6502.org/JSSim/expert. ... 00a10091ff