GID #j - Signal Generation

Having fixed the delay code I’ve spent most of the evening reading up on the SX52’s memory architecture and the PAL timing signal. To start with I’ve created the signal needed for each scanline (see previous blog with timing diagram)

The first attempt didn’t go too well

It was only a few minutes though before I realise my timing was out by a few clock cycles. The reason? Well in order to generate the SYNC pulse 0.0V on the RE port for 4.7µs a delay of 4.7µs*1000/12.5ns = 376 clock cycles is needed, so I did the following

mov RE, VID_SYNC
DELAY(376)

The problem though is that 378 clock cycles have been taken up and thus the code is executing for 25ns longer than it needs to. When all the other mov/delay statements throughout the signal generation code are summed, that’s quite a lot of cycles out of sync. The solution is simple, a mov takes 1 cycle or in the case of a compound mov (which this is) 2 cycles, so reduce the delay by 2 cycles to give

mov RE, VID_SYNC       ; 2
DELAY(376-2)           ; 376-2

The result is a lot more promising. Using VID_WHITE (1.0v) for the output port RE gives a nice white screen. It’s not quite finihsed however, there is no handling of the vertical sync yet. Yes, the following image is a screenshot of a white screen ;)

That’s as far as I managed to get by the end of Saturday. I expected to have a good few hours Sunday to work on getting the vsync sorted and plotting a specific pixel, but plans changed. If I’m lucky I’ll squeeze in a few hours Sunday night to hopefully finish things off.