Data is transferred via parallel and clocked in using a digital pin. Some commands do not require new parallel data unless you need it to change, so the clock pin can simply be toggled for the number of operations in the command.

To take advantage of this feature even more, I want to speed up the toggling of the clock pin.My schematic below is what my idea is at the moment.

I use an LCD shield so pin 'B' ( connected to shield ) would be set to input for high impedance to disable it ( hopefully ).A spare pin 'A' is used to create a signal for a XOR gate, which is split, with one input delayed using buffers.

Is this a common way of creating a pulse on both the HIGH and LOW transitions of pin A?Also, is this the right way to connect the two Arduino pins together allowing me to "hack" the LCD shield?

Yes, its a 320x240 262k ( running in 65k mode ).The 'Write Data Setup Time' is 2.5 ns, hopefully I can squeeze many toggles into the 62.5ns pulse. I also have plenty of buffers to adjust timing.

I'm doing a fast graphics driver for it as the UTFT library is too slow for what I need. For the test this hardware will benefit, I have gotten full screen random colour paints down to 97ms over the UTFT 560ms with simple software changes; with the toggle frequency doubled or even quadrupled, the draw/clear speed will hopefully be much faster than manually erasing paths during animation.

I'll give a try at the circuit in a little bit, just need to find the best way of wiring the pin to the shield.

Not with a 16MHz AVR, that's the cycle time so the best you can do is double it, at least with that circuit. BUT you can't update the data in anything like that sort of time plus presumably the code has to do other stuff, so surely this pulse width is only a small part of the overall job.

I guess though that if the data remains the same, say when clearing the display, doubling the clock will help.

The LCD runs off 16-bit parallel with 16-bit colour so for lines or filled squares where the colour information is static, all that needs to change is the clock write cycle. The screen supports windowing so X and Y address counters are maintained by the LCD.

My plan is to combine a variable frequency multiplier with a duffs-device style rendering loop to limit the number of iterations used in each loop. For now a 2x multiplier will buy me enough CPU time to start testing other features.

I'm pretty sure the 5ns is the correct value, it was the tDHW ( Data hold time ) value.The display controller is SSD1289 and its the 3.2" touch panel from sainsmart running on a mega via a level shifting shield.

The code I'm writing I plan to release to the forum, which will hopefully raise the bar a little bit for Arduino's gaming capacity. The code is tied to the controller, but from browsing the 'display & LCD' forum it seems many people are using the same kit I bought.

I want the hardware support to be modular so its not required for use, but a complex counter like what you describe would be amazing for parallel processing, even if it is only used to clear the screen. As most designs may only need 1 or 2 pwm for sound there are many pins left over for all sorts of fun things.

I have had all sorts of ideas brewing, I was inspired when I saw it was quicker to control than the B/W ST7920 I was using for ages.

The data hold time is how long the databus has to be stable before a write-strobe, its nothing to do with write cycle-time. The write-cycle time is listed as a minimum of 100ns,Looking at other similar device's datasheets suggests the minimum nWR low time is 50ns, minimum nWR high time is 50ns.[ i.e. 10MHz max strobe rate ]

My practical experience with other similar TFT driver chips suggests that clocking at 10MHz is quite do-able and stable. That's 130fps for a screen-fill at 320x240 pixels BTW.

[ The SSD1289 datasheet seems to be bogus and suggests 8080 mode write cycles are strobed using nCS, whereas the standard 8080 interface uses nWR as the strobe - I suspect a bug in the datasheet as the UTFT library assumes nWR and clearly works ]

[ I will NOT respond to personal messages, I WILL delete them, use the forum please ]

The UTFT and others aren't taking advantage of the displays hardware capabilities ( not in data sheet either ), they set data into the the parallel outputs ( colour info ) then pulse WR once. This 'set colour & strobe' is repeated for the fill. In mine, WR is simply pulsed.

I'm already pulsing the LCD as fast as the mega can write. Which is why even, without a frequency doubler I want to use a low-order port to provide the pulse as the high-order ports ( lcd shield connection ) require atomic blocking, effectively halving the toggle speed.

I'll start to de-solder the shield pin now, to see if a simple pin change has any effect, then I'll at least give frequency doubling a go.I'm curious to see it run even close to 130 fps.