Whilst the new approach was mostly working it had had a negative affect also, the introduction of some hideous distortion. \u00c2\u00a0I have tried a few different things to isolate the causes of this and a solution but was rapidly losing hope at finding the problem.<\/p>\n
Thankfully I decided to take a break from it and my latest attempts at solving it, and not more than about 20 minutes into the film (V for Vendetta if you are interested), it struck me!<\/p>\n
The production of the sample data during the VBI was fine, however I realised that whilst it was generating this sample data it was also blocking all other CPU based interrupts, which would of course block the 8kHz feeder interupt that is feeding the sample data to the DSP! \u00c2\u00a0I managed to resist the urge to stop the film and try it there and then.. which meant I got to enjoy the rest of the film, but try my idea out at well past coding o’clock.<\/p>\n
The result? near perfect success! Instead of running the whole sample rendering routine within the VBI, I simply triggered it from the VBI and bingo! \u00c2\u00a0This is lest than ideal of course, but as this is prototyping at this point it’s not really a concern.<\/p>\n
I did also try clearing the interrupt latches earlier in the VBI handler to allow other interrupts whilst the sample render ran, but this didn’t seem to work too well, I shall investigate further, I suspect it may be due to the processor having not yet returned from the exception, possibly making it less tolerant of other interrupts. \u00c2\u00a0Quite pleased with myself \ud83d\ude42<\/p>\n","protected":false},"excerpt":{"rendered":"
Whilst the new approach was mostly working it had had a negative affect also, the introduction of some hideous distortion. \u00c2\u00a0I have tried a few different things to isolate the causes of this and a solution but was rapidly losing hope at finding the problem. Thankfully I decided to take a break from it and … Continue reading Getting there<\/span>