In honor of 10K+ views and especially for those who have helped me progress to this point, I post schematics, including Richard Herveille's I2C core.
Still working on drivers for it, but everything else is functioning with his core present , including the 2 external 4.7K pull-up resistors for SCL and SDA.
The FPGA has an internal pull-up function too, but I think I read they're only good for around 12K.
His documentation is abit tricky, so I am forced to interpret his VHDL, as far as his register assignments and that even is a little tricky.
His registers seem to change based on whether his I2C Master Core is reading or writing to a device, I'm not sure why... But I do intend to use his core for write only operation. So I think I have it straight.

This is the 6502SoC Top_Level Schematic so far (I'll try to fix the blockiness of the smaller fonts):


Here are the modules from above:
Clock Control Module
TimingControl Module
Addr_Decode Module
DataOutRegisters
DataInMUXx
IO

Gonna hold off on working with the I2C Core at the moment, but I'll still leave it in. Need to get the PS2 Core up and running with a keyboard scan routine.

This project is taking a slight trajectory change, and it has to do with software, which has to do with the internal ROMs, which have to do with the hardware design hence my post here. I had originally intended (I hear myself saying that alot ) to put the machine language monitor along with whatever routines it was going to use from the C64 Kernal and Basic ROMs. I was picturing "cutting & pasting" these routines...
But I've decided to include the full C64 Kernal, Basic, and Character ROM's. In fact I have already integrated them into the schematic along with Daniel Quintero's PS2 Core. So all the ROM's are occupying 24K, and I have a 1K RAM at the bottom of memory. ISE is saying 81% of RAMB16s are being utilized. Which leaves about 5K for future use at this point...
Everything passed synthesis, but there is one negative.
Anticipated top speed now is down 10MHz to 44MHz. Still not too bad.
I am anxious to begin testing! Now focused on getting that Micromon image.

I finally got a reliable Micromon image and disassembled it in MK's macroassembler!

It is only using 6 routines from the C-64 Kernal. I will have to replace 2 of them, to get it semi-functional, with my own routines for the keyboard in and display out.
Later on, I'll make the save and load routines for the Flash memory, instead of the original cassette and 5 1/4" floppy device ops.

I have chosen not to incorporate the C-64 Kernal and Basic ROM's into the XC3S400.
If I did, it wouldn't have left enough memory for BASIC to work 100% reliably. Although, it will be for a future side project incorporating a 144-pin QFP Spartan-6 (BTW, they're now in stock for the slower -2 speed grade!! WOOOOO(I just ordered 6)) which has 576Kbits (i.e. 72Kbytes minus some for cpu and logic FF's = 64K+). Would be very interesting to run C-64 BASIC, SUPERBASIC, and other non-sprite/non-graphic programs at higher speeds....

But right now, I just need a functional 6502 monitor to make progress. Progress that will funnel down into the 65816 controlled PWA Project, although only in 6502 compatibility mode, at first.
In that project, I do plan on utilizing the T65 Core and trying to analyze the extent to which it has backwards 6502 compatibility, along with forward 65816 functionality, with this forums' help...

Also, just FYI:
1)There's no intentions to change from Arlet's 6502 core in the 6502SoC.
2) Rethinking RDY here. May just need a 1 or 2 cycle delay just like an original 1MHz 6502 because RDY is only active during the I/O device's active chip select.

The next 2 days I focus on the PS2 and I2C cores. If I have early success, I will focus on RDY again...

Having problems trying to make a 16,384 byte ROM with the bin2coe (and bin2coeV2) converter. It's making the .coe file, but it doesn't contain the full 16K. I don't think it even worked for 8K. I've been having problems ever since I combined the original 4K C64 character ROM, the 4K monitor program and my software. Worked for me making a 4K ROM though. Shoulda ran ISim along time ago...
Can anyone confirm please?

isim will be the quickest way to see what's happening.

In isim you can force signals to certain values. So you only need to run your simulation for a few cycles after reset: force the address bus to some value, and observe the data bus to see what the ROM contains at that address. After a few runs you'll see what you have where. (There might even be easier ways, but that springs to mind.)

The question you're trying to answer is: what's in this design? Once you have that answer, the next question is: how did that happen?

(I'm not using coe files so I don't know what the limitations or pitfalls might be - nor do I have a huge ROM at this point.)

BigEd, thanks for responding. Here's what I'm working with:
I've got a 16K ROM from $C000-$FFFF. Reset, IRQ, and NMI vectors point to $E000, where my software starts to init the display, and clear the screen, etc. Stuff I've tested already... At $C000-$CFFF is the 6502 monitor I've mentioned. $D000-$DFFF data is from an image of a 901225 C-64 character ROM.

I did in fact run ISim and saw that it was starting and reading from an incorrect vector, which made me inspect the .coe file for the correct binary data in notepad. bin2coe is not converting the entire 16K worth of binary data. So I reinspected the 16K binary file, and everything seems to be good there at the binary level. Problem is at the .coe level, heck the .coe file that bin2coe made is only 6.5K. Hence my post about the bin2coe program. Maybe I hit a limit of some kind?

ah, sounds like a bug... if you're not able to build it yourself, you might have to wait for someone who can rebuild it for you. Sorry, I can't help - not in front of the right kind of computer.

(I wonder if it hit a ^Z and saw that as end of file?)

Perhaps you could put your 16k binary data up somewhere? If nowhere else, sign up for dropbox and use their public folder mechanism. That'll make it a lot easier for someone to reproduce your problem.

I see that the windows version of the bin2coe program has a problem when there's a CTRL-Z in the bin file.

You can find a fixed version here: http://ladybug.xs4all.nl/arlet/fpga/source/bin2coe.exe

Excellent, thanks! The semicolon should be EOF. I'll try it out

F'ing A that was it!:evil:
PS/2 core working and displaying characters typed on screen! Many thanks!

Damn control Zed!!! What ascii value is that?

Next tue&wed will add I2C core back in, software already ready...

ctrl-z = 0x1A

Arlet, let me pick your brain here for 1 moment, or anyone else versed in Xilinx FPGA's...

During this last "episode" of a week+ long troubleshooting, some questions have come to mind. But 1 primary question still remains...

ISE had previously spec'd a top speed of my project right around 37MHz at one point. However, the main DS1085 oscillator feeding the Spartan 3 DCM is at 48.58MHz...
When ISE spec'd a top speed of 37MHz, does that max speed spec apply to a DCM or to everything after a DCM?
i.e., are the DCM's on the four corners always capable of running at the highest speed of the FPGA device spec'd in the Xilinx spec sheet (which would be many hundreds of MHz), or are they (the DCM's) limited by the spec's synth'd by ISE?

The max speed is the speed after the DCM, but the tools also understand the DCM, so if you have timing constraints on the clock feeding into the DCM, and you have constant divider/multiplier ratios, the tools will verify your design correctly.