AutoVIDC 2.11

[PaulV]

In the couple of months, I've had only a small amount of time to have a look at my Arc's and when doing so, I spotted a couple of issues with AutoVIDC 2.09/2.10 when running AutoVIDC on an A5000.

From a cold (and I mean temperature cold) boot, AutoVIDC 2.09/10 work perfectly. However, once the machine has been on for several hours, if AutoVIDC is re-launched the clock detection code fails to detect some or all of the clocks correctly. There's no real problem or bug in the code, simply that the ranges of interrupts that AutoVIDC expects to see for specific clock speeds are too narrow by one or two interrupts either way as the machine appears a little faster or slower depending on which clock is selected during the detection process.

To that end, I've built and have been testing a new version of AutoVIDC with the wider ranges in place and it seems to be 100% reliable when detecting clock speeds even if the machine has been on for 24 hours.

About two months ago, I also added in a couple of new SWI's which allows a developer to ask if an enhancer is present and what type of Enhancer it is using SWI's:

• AutoVIDC_EnhancerPresent
• AutoVIDC_EnhancerType

These two SWI's can be used to modify applications like !ArmSI so that they can report on the exact VIDC enhancer hardware if any is present.

Hopefully, I'll get the time over the weekend to package it up and upload it here for further testing by others.

Paul

[JonAbbott]

Hopefully, I'll get the time over the weekend to package it up and upload it here for further testing by others.

Just the module will be fine for testing with ADFFS, it simply needs dropping in the !ADFFS folder and I'll include it in the next release. Attach it to a post if you don't mind it being publicly tested.

How can you tell if its working correctly? Is it obvious and does it show up with LCDgm? Will the A4000 potentially suffer the same problem?

[PaulV]

The clock detection code is the same for all Arc's from the A300 through to the A5000 in that it counts a number of interrupts based on the speed of the VIDC clock and the count returned should fall within specific ranges for specific clock speeds. Once the machines have warmed up a bit it seems the interrupts are running fractionally faster for the most part so the number of interrupts was falling outside of the defined ranges resulting in a "non-detected" clock speed.

This means that modules like LCDGameModes which ask AutoVIDC for info about what clocks are present may have received incorrect information. As AutoVIDC should usually be launched early on in an original Arc's boot cycle it's unlikely that it would have caused a problem there ever. However with the younger machines where AutoVIDC isn't required for a lot of its functionality and need only be launched on demand then there's scope for the detect code to be running on those machines after they've been on for quite some time.

I've got a little test program which I can tidy up and let people have which loads and unloads AutoVIDC multiple times and will halt if it encounters a non-detected clock scenario. I can tidy it up a bit so that it'll do an initial detect, ask to confirm if it's correct and then proceed with the loop test comparing the results of a confirmed correct detect with subsequent iterations. That should work nicely.

Paul

[PaulV]

Ok, whilst cleaning up and testing with my BASIC test rig, I've discovered that the ranges defined for characterising the clock speeds are *all* out on *all* machines depending on the screen mode used. The issue as I first characterised it is definitely there but by addressing this more fundamental problem by widening the interrupt count ranges to accommodate the inconsistencies of counting interrupts when in different screen modes fixes that issue too.

This new issue is particularly apparent with MODE 28 as it's the highest bandwidth mode that RISC OS drives and it has a big impact on the number of interrupts that AutoVIDC counts. In MODE 28, I was easily able to replicate a non-detection of a 25.175MHz clock because the number of interrupts was lower than expected and it was falling into defined range of interrupts I was using for the the 24MHz clock. The same was happening with the 36MHz clock in that sometimes it was not been accurately detected as the number of interrupts counted was outside the defined range.

After much playing about, making the test run for 50% more time (30 ticks instead of 20 per clock), characterising the behaviour, I've managed to come up with a set of ranges that appear to work in every RISC OS 3 screen mode reliably when running the test for 20 ticks per clock. At least, I've just run a test from 02:30 until 11:00 this morning killing and re-loading the AutoVIDC module every 2 seconds, comparing the results of the re-detection against a set of manually confirmed values that my BASIC program gets from AutoVIDC when the BASIC program was first run.

I'll be zipping up AutoVIDC 2.11 and the BASIC test program this evening and uploading it for testing by others but hopefully it should simply be a confirmation of my findings and the clock detection should be reliable on all the machines tested on.

Paul

[PaulV]

Attached is the AutoVIDC 2.11 beta version and a small basic program to test the thing.

If you place the AutoVIDC module in the RAM disc and run the BASIC program, it should load the module, check the clocks with you to confirm the detection is correct, then go into an infinite look killing an re-loading the module.

On the re-load, the clock detection runs again and if at any time the BASIC program notices a deviation from the clock speeds confirmed at the start, it'll stop and show you what it found.

Paul

[steve3000]

Good bug hunting work Paul, and very thorough testing! I'll be happy to test the new version on my Acorns next weekend (away from home 'til then unfortunately).

If you do still get problems, there are another few options to consider - the first being to force VIDC into a known low-bandwidth state eg. similar to DMPS powersave mode or the RISC OS screensaver (make HBSR=HBER), so no bandwidth is spent on displaying the screen. The screen will briefly go blank (but it already does that to some extent - if the monitor doesn't latch on during the test), you then make your readings, and restore screen after. Another option is just to force into Mode 0 and make the readings (perhaps only if Mode=28 or =21 on loading), but you would get the 'press space or click mouse to continue' message afterwards though if run from desktop, as RO will detect a VDU write.

Mode21 and Mode28 will always be more likely to show problems, because when you feed 36MHz into VIDC, they will struggle - the MEMC will complain, and interrupts may get missed... Particularly on Arm2 / 8MHz memory.

[JonAbbott]

If you do still get problems, there are another few options to consider - the first being to force VIDC into a known low-bandwidth

I was going to suggest something similar, I remember having to do this in !ARMSi so it could work out the instruction timing accurately. I think it was accurate to within 2% with VIDC not taking bus bandwidth, done over a 1000 instruction test.

Looking at the code, I was using the following to shut off Video/Cursor/Sound DMA:

Code: Select all

SYS "OS_UpdateMEMC", 0, %11 << 10

And to re-enable:

Code: Select all

SYS "OS_UpdateMEMC", 0, %11 << 10, %11 << 10

I'm not sure how you're working out the timing though, does it need DMA enabled to work?

[JonAbbott]

Is this out of beta and ready for release yet? I'm aiming to release a beta of ADFFS soon, can I include this version with it?

[PaulV]

Sorry for the delay in getting back to you. I've had no feedback either way from anyone but it seems stable enough on the clock detection front. I'm extremely busy with work and I'll be in New York until the 13th Jan. so I don't have the time to update the docs with the extra SWI info at the moment but I'm happy to release it based on my own test results. The extra SWI's aren't essential to running, they just help other programs identify exactly what clock selection hardware is installed.

Paul

[JonAbbott]

Great, I'll include it in the next ADFFS release which should be any day now, just need to iron out a bug in the JIT when games are claiming / releasing vectors.

I must admit, I've done no testing on pre-RISC PC for a few months now due to the amount of coding I've been doing on the JIT for StrongARM and Pi support. That said, as ADFFS went on a diet so far as RO3.1 goes, I need to test ADFFS, AutoVIDC and QTM thoroughly before release. I don't suspect any issues, but will feedback and confirm.