And it's why the DE1 feeds the same clock in on multiple pins. Shame they forgot this trick on the DE2!

It's worth googling the exact error message, just to see if there is an easy answer, but I suspect not.

I can think of a few ways to work around this (in order of difficulty):

1. Use one PLL to go from 50MHz to 32MHz and a second PLL to go from 27MHz to 24MHz (and drop the second scan doubler).

2. Use one PLL to go from 50MHz to 96MHz, then a /3 counter to get 32MHz and a /4 counter to get 24MHz.

3. Use a fast counter to generate a 24 and 32MHz clocks that are not quite regular, but have the right average frequency. See here for an example. This is quite hard to get your head around, so I'd try the others first.

The DE2 looked like a good purchase on eBay when I looked at number of LEs and IO pins, but in hindsight, maybe not.
In a positive note, it didn't cost all that much and I guess it's good enough for learning the ropes.

Each PLL can be fed by one of four single-ended or two differential clock
input pins. For example, PLL 1 can be fed by CLK[3..0] when using a
single-ended I/O standard. When your design uses a differential I/O
standard, these same clock pins have a secondary function as
LVDSCLK[2..1]p and LVDSCLK[2..1]n pins. When using differential
clocks, the CLK0 pin’s secondary function is LVDSCLK1p, the CLK1 pin’s
secondary function is LVDSCLK1n, etc.

Does this help us at all?
I don't know what a single-ended clock is, but the text seems to indicate that you can share e.g. the 50MHz clock among PLLs. E.g. CLOCK_50(0) and CLOCK_50(1).
Or am I grasping at straws here?

There is 1 m (multiplier) per PLL
There is 1 n (divider) per PLL
These operate on the fREF to give a fVCO

It then goes on to say:Each output port has a unique post-scale counter to divide down the
high-frequency VCO. There are three post-scale counters (c0, c1, and c2),
which range from 1 to 32.

However, the MegaWizard dialogue screens give the impression that you have a N and an M for each of C0, C1 and C2, which would seem to contradict the above(?)

Maybe my failure of reasoning is that I have regarded C0, C1 and C2 as end products, i.e. output clocks to be used by various elements in the design? I hesitate because of the manual's wording where C0 etc, are called "post scale counters" not e.g. "clock outputs"?

I guess this confusion can be cleared up with a bit more study, but it connects directly to my failing to understand how your suggestions work.
I.e.
- use m=16,n=1 to get fVCO of 432MHz ---> Yes, I can set this up
- use c1 = 18 to get 24MHz ---> Ehhh? *lots of head scratching*

adrm wrote:
I guess this confusion can be cleared up with a bit more study, but it connects directly to my failing to understand how your suggestions work.
I.e.
- use m=16,n=1 to get fVCO of 432MHz ---> Yes, I can set this up
- use c1 = 18 to get 24MHz ---> Ehhh? *lots of head scratching*

I think this is confusing because the Wizard generally tries to hide the actual values of m, n and c, and instead shows the multiplier / divider ratio in it's simplest form.

In my description above, I've ignore k (the VCO post scale counter), which is not to be confused with the individual clock post scale counters. For now, just assume it's value is 1 (i.e. it's not there!)

The four possible clock inputs on the left correspond to physical input pins on the device. On the DE2, only one of these wired up.

P.S. Your picture of MODE 6 text looks perfect! The character rounding you might be remembering is only in MODE 7.

Thank your for taking the time to go into detail, Dave. This is proving to be just as much fun as I had expected. I hope it's not too frustrating and time consuming to you. I expect you'll let me know when you've had enough

What you show above is exactly what I had set up, so I'm probably just confusing myself at this point.

Just one more question for the moment.
You say:PLLA:
- start with 27MHz and pass this through (the clock control block allows direct use of the clock input)
- use m=16,n=1 to get fVCO of 432MHz
- use c1 = 18 to get 24MHz

Does the underlined part mean that I can use the 27MHz clock BOTH as input to a pll AND as a clock input for other parts of the design, i.e. in paralell with the pll?
Or am I misinterpreting and you're saying that IF the 27MHz clock is fed into a PLL, it MUST be also passed though the pll and output from this without conversion (along with the scaled 24MHz signal)?

adrm wrote:
Just one more question for the moment.
You say:PLLA:
- start with 27MHz and pass this through (the clock control block allows direct use of the clock input)
- use m=16,n=1 to get fVCO of 432MHz
- use c1 = 18 to get 24MHz

Does the underlined part mean that I can use the 27MHz clock BOTH as input to a pll AND as a clock input for other parts of the design, i.e. in paralell with the pll?

Yes, that's correct, at least for Altera FPGA.

BTW, I'm just having a go at this myself (i.e. using a PLL to go from 27MHz to 24MHz).

Just to make sure there are no further gremlins.

Edit: Which it seems there might be, as I'm currently experiencing a very unstable mode 7 display doing this (the columns of flickering/ghosting characters)

adrm wrote:
The mode 7 display looks pretty awful, as Dave found.
Apart from the question of "is it worth the effort", I'm wondering if this is fixable, or just a limitation one has to accept?

If you compare to the pictures I posted earlier, is what you are seeing the same, or worse?

The problem with MODE 7 mapped to VGA boils down a combination of:
- the weird 480x500 resolution of Mode 7, c.f. 640x512 in other mode
- this not scaling "nicely" to a VGA resolution (e.g. at 720x576 or 800x600, 1 pixel maps to 1.5 pixels)
- alternatively, if you scale pixels 1:1 the screen looks very squashed
- doing anything clever (e.g. using a higher VGA resolution) would require a whole frame buffer, which is infeasible in a small FPGA.

hoglet wrote:
If you compare to the pictures I posted earlier, is what you are seeing the same, or worse?

Umm ... now that I actually compare to your picture, I'd have to say mine looks better.
For example, the legs of an M have the same width.

I haven't fired up my real Beeb in a while, due to space limitations, so it's possible I my memory of MODE 7 characters is off.

hoglet wrote:
You need to get yourself a TV with a SCART input. The sRGB mode is indistinguishable from a real Beeb. Do they exist in Norway?

I guess you can find cheap TVs with SCART inputs, but there are none where I'm staying at the moment (90% of my belongings are in storage after I sold off my house, and I've been living in a limbo contemplating relocation to a better climate *sigh*)
I'm stuck with whatever fits on a single desk, for now.

hoglet wrote:
BTW, I do have another project, using a Raspberry Pi Zero to convert sRGB to HDMI, and this does a rather better job. This works with an original Beeb, so should work with BeebFPGA.

I have used this program in the past, with a Pi3, iirc. But with the Pi, PC formatting did just as good a job, so I never gave it another thought.

Well, it seems everything is in working order now.
If anyone wishes to add this to GITHUB, feel free (I don't have an account). Maybe there is another DE2 newbie out there
(I should probably try to rename the project to "bbc_micro_de2" first, though?)

I can now start studying the Beeb project code and pick up more VHDL pointers. Good times!

Again, thank you very much Dave (and anyone else who contributed)
It's not entirely unlikely that I have the odd question, now and then.

adrm wrote:
If anyone wishes to add this to GITHUB, feel free (I don't have an account). Maybe there is another DE2 newbie out there

If you could upload the working code to dropbox, I might have a go at adding this in next week. It's always tricker to get a new target working than you might first imagine. Lots of traps for the unwary, but a great learning experience (for me as well!).

Fingers crossed that 2018 can be the year I finally get a reliable FPGA based Beeb/ Spectrum. My first computer was a 16K Spectrum. My brother gave me a BBC system just over a year after that. Next year I should get my Spectrum Next.

A port of Beeb FPGA would be the making of it for me. I have a software project planned for next year to run on the PiCopro.

I will have to wait a little longer as I could not resist getting the cased version.