I am familiar with synchronizers. I'll have to look into it again and would appreciate your help when the time comes. I'm back to trying to get this thing running @48MHz.
Today I made a little progress and was able to get ISim to run a simulation. Instead of writing a testbench in a HDL, I was able to force NMI inactive, active reset for a initial time of 5000ps, and force a 20.58ns clock for O2. Below is a pic from ISim with system successfully running @24MHz. One thing I don't understand is the display (chip select) signal goes low 3 times and that's it? I ran the sim for a full 8sec and it never again goes low, even though the display in real life is constantly clearing the display with incrementally changing colors.

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

What you can do is add the signals for the internal PC, and A, X, Y registers. That way you can see what the CPU core is doing, and if that matches what you expect.

Exactly, and possibly the IR as well, cuz I don't get what the data bus is doing. I can't see an instruction fetches, or are they strictly internal ?

@PontusO. I will post another pic with IR and address bus. O2 feeds a divider. O2Out is what the display sees. An inverted O2Out is what the internal core/RAMs/ROM sees as per this schematic.

I should have included the address lines as well. Looking at them reminded me of the fact that I had increased those 2 delays from what I had posted above because I had increased the speed of O2 to 24MHz from much slower speeds. I think what I thought was 8sec's was maybe more like .8sec's...Turns out the display still init's ok with those short delays @24MHz.

Looking at A0, Display, and R/W with respect to O2out, it is in spec with the SSD1963 datasheet (Fig.13-2 on pg. 78.), even at 48MHz.
At this point I'm thinking the values I have for initializing the display are not up to speed. I would think, for example, the pixel clock would have to be faster that the O2 speed? I suspect this because right now the pixel clock is set for 33MHz.
I'm focusing on 2 registers, $E2 (Set PLL frequency, Pg. 72) and $E6 (Set Pixel clock, Pg.74).

Any comments or suggestions? TIA

A better insight:

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

Looks like you're happily in that tight loop running DEX. Is it worth loading a smaller value than FF so you can see what happens when you hit zero?

Yep, that is definitely what's going on there. Is it possible to switch to hex notation on the signals ?It would make it easier to study the execution flow.

This is by far one of the most interesting threads right now. Keep up the good work.

/P

@BigEd. I should have thought of that earlier. Somewhere in the datasheet I remember reading that a delay was necessary only durint INIT'ing the PLL/timing registers. The delay values spec'd were different. One was in the uS range, the other delay was even longer IIRC. Anyway this may give me a clue if I see something similar as to what I am seeing now attempting 48MHz. Most of the time I do see an incorrect display initialization, although it is repeatable most of the time, and data is very clearly passing to the display albeit incorrectly. Sometimes I see color data, but all the sync's were wrong. This tells me Arlet's core is functioning fine at 48MHz... When I have a few hours, I will test those display delay settings to destruction, i.e. a non working display @24MHz. Just FYI at 24MHz, the screen is clearing at maybe 3-4 frames a sec at 640x480x3x8bits.

@PontusO. I'll try to find out about changing those values from binary to hex in ISim.

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

After removing the software delay, the display INIT routine has no visible effect on the display @24MHz, nothing at all...

Another issue: While trying to conform all FPGA outputs to the display for active low outputs, I am puzzled about the following: The "A" R_W circuit works. For some reason, the "B" R_W circuit doesn't. Why would this be so? It's right in the middle of the current schematic.

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

Hi EE
on the subject of the delay loop, I was suggesting you shorten it (dramatically) for the purposes of seeing more on the simulation - you might need to keep it the same for the real circuit. (I think you said that the simulation never did any more writes after the first three)

on the subject of R/W, one of your gates will invert the sense of O2, and the other one doesn't - so that will make a big difference as to which phase the output will be active.

Cheers
Ed

I am only doing a screen capture, so without it being too crammed and unreadable, only small portions of code can be seen. Would be nice if I could have it scroll horizontally. If someone is aware of a utility I could use, I'll try it in the future...
But after I realized I had extended the delays, then brought them back down to what I had shown in code and reran ISim, the display signal is going low and being written when it's supposed to, i.e. when $C000,$C001 are on the address bus. Sorry for not explicitly saying that before.

About the N/AND gates. I see what you're saying (I was over-simplifing things and thinking of truth table only) and it gives me an idea to use the NAND circuit for R/W and take out the inverter going to the TFT O2. Also, I'm going to try to change the slew rate from slow to fast and retry 48MHz. Will have to wait till after work...
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Didn't work correctly. I'll do a sim and compare waveforms in a couple days. I have a suspicion that pulling A0 from the internal address to an external pin is creating some kind of contention/delay between the display decode and A0. We shall see in ISim in the next few days...

One other note to those who may be beginners to FPGA design, like myself, interested in Xilinx products: I've discovered the official Xilinx youtube channel and there seem to be many beginner tutorials there. I'm looking over the global timing constraint vid's right now, that is when I've got some minutes free at work (I just got mobile internet!). Just search for xilinxinc on youtube.

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

Finally got around to using a DCM to divide the 48.58MHz down to slower speeds. Very useful to use as you input 2 numbers, a multiplier and divider, to get the final frequency. The fastest I could get everything working was 38MHz(48.58x(4/5)). By working, I mean for a least a minute. I've gotten away from using the OFFSET = OUT constraints. The only constraints I've specified is the LOCATION, IOSTANDARD, O2 PERIOD, and SLEW = SLOW. Setting SLEW = HIGH seems to make things stop working quicker. Most likely due to more noise. Following this thought, I tried to lower the default 12mA output drive current to 4mA. Things ran MUCH better. Retrying 40MHz was still unfruitful though.

Although I would have liked to push the speeds even faster by using a VGA core, a good amount of external memory would've had to have been used for any decent resolution with colors.

There's nothing to rule out using another 6502 core at faster speeds to control something else, once I'm further along. Got my eye on those neat looking dual port RAMs and ROMs..

Right now though, it's time to wire in the bypass caps. I know some probably have thought I have skipped a most important part to any high speed electronics project, but I sorta felt comfortable in diagnosing any major malfunctions or random data, and also felt confident in my power layout.

Next on the list is to add the PS/2 core for the keyboard and polish off the software that reads it. I never did get around to "trapping" shift keys. This next part will be stressing the ALU abit more as the character plotting is not as simple as just sending repetitive data to a screen. Also it uses BCD mode for hex to decimal conversion. But, the software is done, and it shouldn't be very difficult to change it from 65C02.

Here is my video proof so far.

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

I think these particular instructions would be fairly easy to add. I think they fit well in the existing state machine and data path. In most cases, all that's needed is a few extra lines in the 'case' statements for proper decoding.

After my first paragraph on my last post, I should have gone on to say that after adding the DRIVE constraint and setting it to 4mA, it is running for many hours! I will still yet hold off on wirewrapping a laborious 28 bypass cap's...

Arlet, are you offering to add your expertise to add those commands for a "mod'd" core? If you are, that would be awesome!!!... But, even if you aren't, I've reread this entire thread last night and seeing how the display I am using was sort of a disappointment as far as testing a 6502 cores' top speed, I think I need to take you up on your original offer and add your 640x480 VGA core controlled by another 6502 core... The TFT display could still be used in a troubleshooter type mode at 38MHz as a master controller/debugger with the current 6502 core along side the PS/2 core. I would strip the RAM/ROM to an absolute minimum for this core. It would also be an I/O controller for the SD card and Flash.

I see your VGA core is good for 200MHz! according to your webpage. I can get 2x 2Mx8 10nS asynchronous SRAM's. This would provide 13 bits of color @640x480 with a pixel rate Max of close to 100MHz. The single most negative about this entire idea is that each SRAM @10ns in a 54-pin TSOP II package demands 275mA each. I anticipate they will add quite abit of noise...

The addition of the 2 SRAM's would force the SD Card connector offboard and the 100-pin QFP CY7C67300 offboard as well, but I don't think that will be a problem. The very high speed ram would be right under the Spartan 3, and the DB15 VGA connector in the upper right next to the Vreg's. I think I will need DAC's too?. Not quite up to par on video, but will be soon.

I'm very excited by this! The last time I did a video project was over 20 years ago in high school, before my hibernation, i.e. my failure in college to be an EE major, even though electronics was my obsession. Too much theory, and I was too young so I had to pursue another hands on career, autos... Anyway, I remember I had used a SMC8002 display/font/cursor generator and the SMC5037 CRTC (I actually wound up using the 6845) controlled by a MOS6502B, and made an 8 bit R2R ladder for 256 shades monochrome and it worked pretty good on a composite monitor. I'm pretty sure I still have those old datasheets too, they included all the formulas to calculate HSYNC, VSYNC, and the final pixel clock. AH, I'm rambling again. I must go check the display...

Been running for 5+ hours now.

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

My VGA timing generator is good for 200MHz, but reading external SRAM is limited to about 100 MHz, and requires good layout/decoupling.

The 6502 <-> external SRAM interface also needs quite a bit of work. Especially reading from SRAM is tricky, because of the different clock speed and dual access between CPU and VGA controller.

So you designed your 6502 core to specifically take advantage of the FPGA's block ram?

First, I think I should try to experiment reading and writing to the 70ns FLASH although I'll be limited to around <14MHz. Maybe it will provide a good foundation to learn the correct timing for the higher speed stuff?
Also, since whatever I have to do to qualify the reads will be internal to the FPGA, I'll still have a very decent insight to whats going on using ISim and will be able to present it here.

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