Moving beyond 8MHz with standard ICs

[plasmo]

Copy ROM to RAM allows a design without any glue logic like this.
https://www.retrobrewcomputers.org/doku ... 6502r1home
To have valid vectors at $fffa-$ffff requires pull up/down resistors for this glueless logic design.

This is my version of ROM-less design with standard TTL logic with the help of FT245R. Unfortunately it can’t run faster than 8 Mhz.
https://www.retrobrewcomputers.org/doku ... og65r2home
Bill

[ytropek]

One thing we didn't discuss in this thread is voltage. According to the datasheet of W65C816 - going faster than 8MHz requires 5V, but I remember I read about some successful implementations of 14MHz SBCs running with 3.3V.
What's your experience on the field?

[GARTHWILSON]

ytropek wrote:

One thing we didn't discuss in this thread is voltage. According to the datasheet of W65C816 - going faster than 8MHz requires 5V, but I remember I read about some successful implementations of 14MHz SBCs running with 3.3V.
What's your experience on the field?

At viewtopic.php?p=92619#p92619, Proxy writes about the '816,

Quote:

it runs stable at 18.75MHz right now (pretty good for 3.3V! ), i also tried 25MHz and according to the built-in Logic analyzer it was executing code normally, but it was unable to write to the IO Register

[BruceRMcF]

GARTHWILSON wrote:

ytropek wrote:

One thing we didn't discuss in this thread is voltage. According to the datasheet of W65C816 - going faster than 8MHz requires 5V, but I remember I read about some successful implementations of 14MHz SBCs running with 3.3V.
What's your experience on the field?

At viewtopic.php?p=92619#p92619, Proxy writes about the '816,

Quote:

it runs stable at 18.75MHz right now (pretty good for 3.3V! ), i also tried 25MHz and according to the built-in Logic analyzer it was executing code normally, but it was unable to write to the IO Register

That's good to hear ... running a 65816 at 3.3v on a board with an FPGA containing the Vera model is an idea that strikes me as interesting. I'm thinking a system clock of 12.5MHz would mean that it could serve as the master clock for Vera as well, which AFAIU internally doubles the master clock to arrive at the internal 25MHz VGA pixel clock.

[Proxy]

FPGAs have PLLs so you can run them at whatever speed you want relative to a video clock. 12.5 seems a little low IMO.
in the case of that post i used the onboard 50MHz clock to generate a 75MHz VGA clock (for 1280x720, which divided by 2 gives you 640x360, slightly smaller than 640x480 but with a modern 16:9 aspect ratio instead of 4:3) and from there divided it by 4 to get the 18.75MHz for the CPU.
the project didn't really get that far, but i do have a second revision of that CPU board lying around with some RAM, ROM, and IO on it so i don't have to reprogram the whole FPGA just to change the ROM code for example.
but i haven't gotten around to assembling the board as i'm currently still fighting with my 65C02 powered VGA card, so maybe another day!

[plasmo]

Proxy wrote:

…i'm currently still fighting with my 65C02 powered VGA card, so maybe another day!

That sounds interesting since I’m also working on (and fighting with) a 25Mhz 6502 as VGA controller.
Bill

[Proxy]

i mean i did already post about it on your VGA controller thread, but i can give a small update over there.

[plasmo]

Thanks for the updates. I got you mixed up with George Foot; for a moment I thought there are three 6502-based VGA designs. Well no, it is just me confused!
Bill

[barnacle]

I mooted the idea and kicked an initial design around, but have so far taken it no further. Perhaps that's what confused?

(I've thrown several ideas in the air about generating vga and svga without programmable logic recently).

Neil

[BruceRMcF]

Proxy wrote:

FPGAs have PLLs so you can run them at whatever speed you want relative to a video clock. 12.5 seems a little low IMO.
in the case of that post i used the onboard 50MHz clock to generate a 75MHz VGA clock (for 1280x720, which divided by 2 gives you 640x360, slightly smaller than 640x480 but with a modern 16:9 aspect ratio instead of 4:3) and from there divided it by 4 to get the 18.75MHz for the CPU. ...

Yeah, the Vera model is aimed for 640x480 classic 4:3 VGA. I guess the community working on the X16 are working on an HDMI version which would output in 16:9, but IIUC, it would just pillarbox from 16:9 to 4:3 for software compatibility with the VGA / composite / S-video / RGB version of the Vera board. I presume that the pillarboxing would entail running the pixel clock faster than the standard VGA pixel clock.

I'm a from-a-long-time-ago software hand taking very tentative steps into the hardware side, so I just read the various VGA circuit threads with interest, I don't expect I would ever design a VGA board from scratch.

[Yuri]

BruceRMcF wrote:

Proxy wrote:

FPGAs have PLLs so you can run them at whatever speed you want relative to a video clock. 12.5 seems a little low IMO.
in the case of that post i used the onboard 50MHz clock to generate a 75MHz VGA clock (for 1280x720, which divided by 2 gives you 640x360, slightly smaller than 640x480 but with a modern 16:9 aspect ratio instead of 4:3) and from there divided it by 4 to get the 18.75MHz for the CPU. ...

Yeah, the Vera model is aimed for 640x480 classic 4:3 VGA. I guess the community working on the X16 are working on an HDMI version which would output in 16:9, but IIUC, it would just pillarbox from 16:9 to 4:3 for software compatibility with the VGA / composite / S-video / RGB version of the Vera board. I presume that the pillarboxing would entail running the pixel clock faster than the standard VGA pixel clock.

I'm a from-a-long-time-ago software hand taking very tentative steps into the hardware side, so I just read the various VGA circuit threads with interest, I don't expect I would ever design a VGA board from scratch.

The Cyclone V board I have includes an HDMI output and a chip that can handle all of that. Near as I can tell it is perfectly valid to send the standard VGA 60Hz 640x480 timing signals over HDMI. At which point the display figures out how it wants to squish/stretch/whatever the picture to fit.

(I however have not yet wrapped my brain around how to effectively communicate with that chip, which needs some initial setup; so I'm going to cheese the signals through the GPIO pins to a regular analog VGA connector.)