Minimig released for real!

[freqmax]

AI = Amiga Inc?, in that case it's not even worth the brain neurons it might occupy ;-)

[freqmax]

@alexh:
I think once the userbase become wider than those with hardware/software/amiga wiz-powers. People with HDL knowledge but not electronics etc.. can fix those NTSC things and other features.
As it is now, only those with a substantial knowledge can even enter the "playfield".

Regarding 50Hz, isn't that a TFT controller board limititation?, can't recall any TFT module having that restriction.

[freqmax]

Guess we better fix 60 Hz mode.. Real Soon.

[freqmax]

No need to change crystal, just alter clock_dcm.v to output NTSC colour frequency.
I looked around on TFT specifications, seems 50 Hz is more doable than 100 Hz. As some of them actually supports 50 Hz. The upper limit seems to be 75 Hz for many screens. However I belive there are 100 Hz capable screens. And the onboard RAM could be used as frame buffer if the video output can't be scanned twice the normal rate.

[freqmax]

Frequency 3.575499 MHz with multiply=25 division=31
Ie 4.433619*(25/31)
If 0.001 MHz deviation works out alright.

[freqmax]

I think it's possible to cascade DCMs. And XC3S400 & XC3S500E both have 4x DCMs.

These clocks can be done without DCM (provided the 28MHz):
28.63636 MHz / 8 = 3.579545 MHz (colour clock)
28.63636 MHz.. (agnus)
28.63636 MHz / 2 = 7.15909 MHz (m68k cpu)
28.63636 MHz / 40 = 0.715909 MHz (E clk)

The key issue is timing, thus the colour coding schemes which another person mentioned is quite irrelevant as output is direct RGB.
I don't think the colour frequency crystal is needed at all actually. One could simple hookup to the MCU crystal and thus eliminate one crystal + associated passives.

I think a pure HDL solution is doable if the slight timing deviation is tolerable.