Well I tried loading the "clive" and "inside" graphics to the memory expansion and found I had huge "jailbars" down the screen. After my heart sank a little, and a little investigation I noticed that pin 40 of the PIC was bent and not in the socket... some fiddling around and I had the pins straight and all in the socket and they all went away. I played with the contrast some and the smearing is a lot better too.
When displaying from the memory I did notice a very slight occasional flicker on the normally blank digits of the display between the address and data fields, so there is still some bus interaction, but I'm not noticing any memory corruption yet. I've been trying to get my head around Karens code again, and so far it looks like there is at least a 3.75uS delay between asserting NENIN and driving the address pins, for example the smallest:
Code:
L5 BCF PORTC,NSYNC ; VDU on
BSF PORTA,NENIN ; Nenin high here
DELAY D'13'
BSF STATUS,RP0
CLRF TRISA ; on hi 4 bus ~15(3.75uS after NENIN)
CLRF TRISD ; on lo 8 bus ~16 (4uS after NENIN)
BCF STATUS,RP0
BSF PORTC,NSYNC
This also explains why my buffers didn't work so well, as I was effectively driving the bus immediately on putting NENIN high! However, correctly implementing the buffers will mean that we can remove the constant switching of PORTA and PORTD between input and output which will give more timing headroom if we need other tweaks to the code, and possibly eliminate other loading effects,
I am trying to think of a way of arranging the firmware code so that its structure is easier to understand, perhaps using more macros for the more repetitive parts of the code. of course this will have to be done with regard to timing, but if I am successful the generated hex file should be identical....
NB: While loading the graphic images I was getting some corruptions because of the keypress timing, so I doubled the default values in send14. This rather crude tweak solved the problems, slowing the process but to be honest not enough to worry me. Id rather it be slow and reliable that quick and flaky. The alternative of course would be to switch off the VDU so it isn't slowing the MK14.