Long load times with colourisation on a pin2dmd

[Wob76]

Hi,

Just wondering if we can look at improving the load time of colourisations on pin2dmd hardware, my understanding is there is a introduced delay to allow pallet files to be loaded onto the hardware before the dmd is initialised. With some of the newer colourisations having more pallets this seems to have ballooned out and is very noticable on some tables (Simpsons PP, AFM, Metallica and MM).

Not sure what approach is best? I change in approach from the hardware firmware (a lucky1 thing) or some sort of variable in the ini that would allow tweaking of this load time to see if it can be safely reduced? I have posted on VPU for lucky1 to comment (here), but thought I would raise it here too and see if you had some ideas.

Thanks, Wob

[freezy]

Is it the same problem with Lucky1's DLL or specific to dmdext's?

[Wob76]

Hi freezy, it is an issue with both DLL's, my understanding is there is a set delay to load each pallet, and this has been implemented the same in both his and your colourisation. With the number of pallets in some new colourisations this is blowing out the load time.

[djrobx]

There is a sleep statement in the palette preloading code that seems strangely long (100ms per palette loaded). Some colorizations have dozens of palettes, if there were 50 palettes it would be sleeping for 5 seconds. Per lucky1 it is the same in his own DLL, but perhaps Lucky1 can help us better understand why this delay is required, if it can be shortened, etc.

The previous version of this DLL programmed the palette with only a 50ms delay at runtime. I've compiled different versions of the code with different delay values for Wob76 to test with. He's reported that it works fine at 50ms and is currently testing lower values to try and find what the lower limit is.

[freezy]

I think the sleep is because the data is sent asynchronously to the bus and we don't want to send the next blob when there's still one transferring.

@Wob76 did you have any conclusions? Should I should decrement the delay to 50ms?

[Wob76]

Hi freezy,

I am currently running a dll with 25ms delay, this has been stable for about a month, no ill effects that I have noticed. With 10ms timing I would see frames not colourised correctly on the pin2dmd (but fine on the virtual dmd), so I think the only risk with running it too lean is that the pallets will not load, no crashing etc.

At 25ms it is noticeably faster, my only concern with recommending 25ms become the new default is the possible variation in pin2dmd hardware, my suggestion would be to make this a variable in the ini file, so that others can modify the timing if need be.

Thanks, Wob

[freezy]

Alright, thanks! I'll put 25ms as default and let it override with an additional option.

[Wob76]

Sounds good, Thanks for all your work.

[freezy]

v1.7.2 now includes an --output-delay parameter (delay in dmddevice.ini) and the default 25ms.