danielj wrote:
Excellent. Any idea why it didn't manifest on any other machines? (this is just me being nosey about the technical aspects of it all)...

d.

So, after a little investigating tonight, the problem should be solved.

It looks like Acorn used different VIDC control register settings for 12MHz machines compared to 8MHz. This makes sense (so I should have expected it!), as the DMA requests will complete much faster on 12MHz machines...looking in more detail, only Mode 10 and above are affected by these ram-speed dependent settings... and I had been using the 8MHz settings for Mode 13 and Mode 15!

However, it is strange that neither Paul or myself saw the wrap-around effect on the various 12MHz machines we have... but memory speed tolerances clearly play a big role here. Perhaps Marc's A5000 just has newer/fractionally faster memory?

There's no surprise Daniel sees the problem with his 16MHz A3020 though!

Marc/Daniel - I'll send you a PM with information on the new version I've cobbled together.

Ergh, found another one that doesn't play ball...
Rotor on Play it Again Sam 1 (which is ROS3.1 compatible). Flickery with corruption on the screen (essentially the same as it is without LCDGameModes).

Some games use custom mode modules that LCDGameModes can't know about. Check to see it this one does and if so I'll may be able to help. Some are more custom than others you see so we may need to build a shim module or two to get these games working.

I've had a quick look at Rotor and ArcPinball, neither use custom mode definitions which is a pain as they're generally easy to fix.

I can re-create the problems you're seeing with Rotor and on the face of it it looks like LCDgm is kicking in but Rotor is doing things with the screen mode itself as well so there's possibly a conflict of some sort going on there.

Rotor is definitely one that Steve will need to have a look at.

As for Arc Pinball the only version I can find is the one on the Superior Collection CD ROM ISO image and I can't get that to run at all for testing. My A410/1 just hangs

So after some assistance from Daniel to get a working copy of ArcPinball to look at this is what I found...

I took a look at the "Flippers" BASIC program in the game folder which seems to be a lot of the scaffold for the game.

It turns out that Flippers is writing directly to the VIDC registers using a custom machine code routine that it calls.

It seems to be passing in an offset and value so Steve will definitely have to look at this one as he's infinitely more familiar with how the VIDC chip actually works to see if anything can be done.

As the game can program the VIDC chip directly from the BASIC code, it may be that it could be "hacked" to detect the monitortype and change what it sets the VIDC registers to automatically and not require LCDGameModes at all...

Thanks for the update on testing. It's not surprising that a few games get past LCDgm. Arc Pinball and Rotor are both very early Archimedes games, I think PIAS was released during the times of Arthur OS? Rotor certainly was. Back then it was every game for itself, undocumented hardware accessing was the norm because OS support was so minimal.

That said, I have some ideas and plans which might help fix games like these, but it would be good to have a few more to test/fix at the same time, so keep posting up problem games ...(Also if you find any good successes of games which really didn't work before and now run fine, let me know).

For the moment, I think I've recently seen Rotor somewhere, probably a box in the loft... I'll try digging that out at the weekend.
Cheers,
Steve

Just to let you know, I've released AutoVIDC 2.10 after some extensive testing and tweaking.

This release contains full on VIDC clock detection for pretty much any VIDC oscillator. It *SHOULD* auto-detect the following clocks:

24MHz

25.175MHz

36MHz

...plus some non-standard ones too including...

31.5MHz

32MHz

40MHz

48MHz

50MHz

60MHz

However it's unlikely that anyone would run a VIDC1a chip at much above 48MHz without some extreme cooling solution in place

The reason for the clock detection routines is to pave the way for forthcoming features in LCDGameModes which will allow it to ask AutoVIDC if a particular clock speed is available or not. This is important because it lets LCDGameModes use better hardware options if they're available.

As an example, LCDGameModes might do something like this which basically asks if the 25.175MHz clock is available and uses it if it is, otherwise it falls back to the 24MHz clock...

martinw wrote:Just checked the monitor and the maximum it will do is 1280x1024 at 60Hz .....

Martin

It's the A3000 which can't cope, not the monitor

The maximum resolution the A3000 can do without a VIDC enhancer is 640x512 at 50Hz, 256 colours (or 640x480 at 57Hz, 256 colours), but with an enhancer it can do 640x480 at 60Hz, 256 colours, or 800x600 at 56Hz, 16 colours.

You're not actually using Mode 24 anyway (who suggested that mode?), as it doesn't work on VGA/SVGA monitors. When you try to select Mode 24, Risc OS substitutes it for a different mode - in your case, Mode 28, because Mode 28 has the same number of colours as Mode 24. Mode 28 is 640 x 480 at 60Hz, and 256 colours. This is the very upper limit of the memory bandwidth, and any disc access has to shut down the video output in order to complete data transfer.

Mode 27 is 640x480 at 60Hz, 16 colours - this is much better for use on an A3000, as the video bandwidth is half that of Mode 28 (or Mode 24 substitute). You shouldn't see any screen blanking in Mode 27 during normal use. Try switching to Mode 28, and you will see exactly the same as you saw when you were trying to select Mode 24 - with blanking during disc access.

Steve

Last edited by steve3000 on Sat Jun 22, 2013 9:33 am, edited 1 time in total.