AutoVIDC 2.09

[PaulV]

Hi All,

I've just uploaded AutoVIDC 2.09 to the FTP server.

This is very much a beta release given the problems I've had getting it to assemble correctly today

This version features full on clock detection, which I've adapted from Steve's BASIC ARM assembler example. As a "feature" of this, on a TFT monitor, the screen may blank for about a second when AutoVIDC cycles the clocks for detection purposes before returning the clock to the one that was previously selected

Quite a bit of the other code in the system has been optimised/reduced in size but the addition of the clock detection code has increased the module size to almost 7.7Kb.

AutoVIDC can automatically detect 24, 25.175, 31.5, 32, 36, 40, 48, 50 and 60MHz clocks which should pretty much cover everything an avid over-clocker may want to fit and you can still tell it what is fitted manually via the * command for the over-clocking oscillator as you could previously.

The module also has a new SWI call.

AutoVIDC_ClockAvailable - This takes in a single parameter but it could be one of two sets of values.

On Entry
R0 - 0-3 -OR- Clock speed in kHz e.g. 25175

On Exit
R0 - 0-3 -OR- -1

On exit, AutoVIDC will respond with either -1 (unavailable) OR 0-3 which corresponds to the value you can pass in on AutoVIDC_SetClock.

Example:

MOV R0,#25175
SWI AutoVIDC_ClockAvailable ; Is the 25.175MHz clock available?
CMN R0,#1
BNE setClock ;If it is, go and set the clock...
MOV R0,#0 ;it's not available so select the 24MHz clock instead.
.setClock
SWI AutoVIDC_SetClock

In a standard environment, the line MOV R0,#25175 could be replaced with MOV R0,#1 as that is where the 25MHz clock would be expected to be.

The reason for allowing the clock speed as a parameter is to let you stick a 31.5 or 32MHz clock in place of the 25.175MHz clock and still able to determine whether a 25.175MHz clock is fitted at all...

Anyway, I've tested this on my A310, A410/1, A3010 and A5000 which pretty much covers every available VIDC1a based architecture and it seems OK.

Monitor wise, it's been tested with my Acorn AKF50 multi-sync and my IIyama E430S TFT. On the AKF50, you can see the screen going through each clock speed. On the Iiyama, the screen blanks for about 1 second whilst the clocks are cycled.

Before cycling the clocks, the current clock speed is stored and then it's restored after the test so everything should work as normal.

Full source code is in the distro. The clock detection code is self contained in a sub-folder called utils.

Paul

[PaulV]

As per the other thread, there's a new version of AutoVIDC 2.09 on the FTP server ready for testing.

It's much smaller than the previous test release and in fact it's now smaller than v2.07 with more functionality so that's a bonus

Paul

[JonAbbott]

It's much smaller than the previous test release and in fact it's now smaller than v2.07 with more functionality so that's a bonus

Looks like it went on a crash diet!

Just tried a few games on the A440/1, seems to be working as expected.

[PaulV]

Hi All,

Just a quick update, I've been doing a shed load of testing tonight and on one test of many on the A5000, the clock detection code didn't convert the number of interrupts to the correct clock speed as the value fell outside the configured range.

Essentially, the number of interrupts was one less than the lower value in the range I'd configured for the 25.175Mhz clock. I've widened all the ranges at their lower ends by an extra 1 to accommodate lower interrupt values. Some of the detectable clocks are so close to each other that I cannot widen the ranges further as they'd overlap and we can't have that.

Given the number of tests I've run, this is a rare occurrence so it shouldn't be too much of a problem and I'm not uploading the module just yet as I want to test further tomorrow to see if the wider ranges are indeed wide enough now.

I've also updated the AutoVIDCStatus command so it can now indicate whether AutoVIDC has truly detected an enhancer or not. This is essentially based on checking to see if any clock speed determined by the clock detection code is over 24000kHz. If any are over 24000kHz then it says "detected" otherwise it says "assumed".

I've checked all this on my A310 by disconnecting the Aux IO control cable and it works a treat. The clock availability SWI also seems to be working as it should with a non-VIDC Enhanced machine too listing only a 24MHz clock. Reconnecting the control cable and re-initialising AutoVIDC works as expected too.

I just want to do more testing on the clock detection front to make sure it always gets the clock speeds right before pushing it out to the FTP server again.

Paul

[PaulV]

A quick update and I think I hit a bug in RISC OS....

Yesterday, I wrote a small BASIC module "exerciser" which I could re-configure to do a few different things. One of the things I did was to run a loop performing an RMLoad of AutoVIDC, access the SWI and then RMKill AutoVIDC again.

The purpose of this was to test the clock detection routine which runs at initialisation and the extended ranges that I'd defined to ensure that they were as wide as needed to ensure the clocks would be detected correctly. The good news is that after >30,000 iterations of this exerciser, the ranges appear to be just fine

I did however encounter a problem....

When I left the exerciser running it would perform thousands of loops but eventually RISC OS would hang completely requiring a RESET. As I was testing on my A5000, I figured this could be down to the hardware as it's lashed together with Kynar so I moved to the A3010 and started the tests again. The results were entirely repeatable so I'd ruled out the A5000 hardware which was good

To keep on with the testing, I went on to simple repeated access of the SWI's. Using the automated process I ran in excess of 500,000 SWI calls from BASIC to AutoVIDC yesterday and it performed perfectly with no errors or hangs etc. so all is good on that front

Now this morning, the hang has been niggling away at me and after reviewing the module code that would be running on the A3010 and A5000, I could see no reason for it so I thought I'd try the same experiment with a different module to rule out AutoVIDC completely.

I changed the exerciser to use LCDGameModes instead RMLoad-ing and RMKill-ing repeatedly. Simple enough. Performing this test has revealed that the hang is not in AutoVIDC (or LCDGameModes for that matter), but in the way RISC OS 3 loads modules. Given that the problem only seems to occur when you RMLoad and RMKill and RMLoad in quick succession for hundreds or thousands of iterations, I don't think this is a particularly problematic issue but it's one to be aware of I guess if you're doing extended automated testing where you need to re-load a module.

I've just repeated the test on the A410/1 as well with the same results. So is this a known issue with RISC OS 3 that I've come across?

Anyway, now I've got to the bottom of the hang and it appears that there's nothing I can do about it, I'll be releasing another update to AutoVIDC later once I've tidied up the master disk image and it should be as accurate and stable as I can make it. (Famous last words!)

Paul

[PaulV]

Hopefully, this is the last test version of AutoVIDC 2.09 that I've just uploaded to the FTP server Functionally it should be complete for Steve's use on using the 25.175MHz clock and it should reliably detect the available clocks on all machines under all circumstances.

Paul

[danielj]

Paul, being the clueless sort that I am, I note that this does do things on machines which have the relevant clocks already (e.g. A3020/A5000), but what are the things it does on those machines?

d.

[PaulV]

On earlier machines, AutoVIDC monitors mode changes and sets the clock as necessary and also provides an API so third party applications can control the VIDC clock if they need to.

On later machines, AutoVIDC disables the mode change monitoring and doesn't automatically set the VIDC clock but it does keep that API available so third party applications can still control the VIDC clock if they need to.

What this means that for the first time ever there's a standard API to control the clock speed of the VIDC1a chip across all Arc's from the A305 through to the A5000 and the A30x0 variants. It also now detects the exact clocks that are installed and you can query any given clocks availability through the SWI AutoVIDC_ClockAvailable by passing in either a slot number 0-3 or a clock speed in kHz 24000, 25175 etc. the response to this query is always the slot number of the available clock or -1 if it isn't present.

So you can do things like this...

Code: Select all

MOV R0,#25175                         ; Set the clock speed in kHz
SWI AutoVIDC_ClockAvailable           ; Is it there?
CMN R0,#1                             ; If it isn't there
MOVEQ R0,#0                           ; choose the 24Mhz clock (always in slot 0)
SWI AutoVIDC_SetClock                 ; pass R0 back into AutoVIDC to set the clock.

This would set the VIDC clock to 25.175MHz if the clock is available or to 24MHz if not on any machine regardless of the hardware involved.

This technique lets Steve's LCDGameModes module verify if a 25.175MHz clock is present on any Archimedes (which could be provided by a WE Super VIDC Enhancer, a dual VIDC Enhancer config, my latest Ultra VIDC Enhancer boards or native Acorn clocks) and if it is, use it, otherwise he can fall back to a 24MHz based screen mode.

Paul

[danielj]

All is now crystal clear, the fug has lifted

[JonAbbott]

Just done some testing on the A4000, along with LCDgm (the version in ADFFS), seems to all work beautifully. I can't thank you two enough for all your efforts in getting these old games working on modern monitors