WE Super VIDC information

[steve3000]

Paul - you'll be interested in this, I'm sure!

This morning I found a disc packed with old code segments I wrote back in 1995... and buried at the bottom of a couple of folders relating to VIDC control, mode definitions and clock settings etc., was sitting a couple of files I barely remember writing - my own investigation of controlling the Watford Electronics Super VIDC enhancer which I had in my A310 at the time.

The first file "Syncer" was my test file for poking IIC control of the super VIDC, while trying to decode what did what. It contains a breakdown of all the sync_select and clock_select settings I determined (all possible I think?), I've copied this below:

Code: Select all

decoding WE super vidc enhancer - (c) phoenix 1995
                                                 __
                                            HV 11HV CLK
                                            ||   || |
   So far &F0 = 36.000MHz, V+ V+ (800*600) %11 1100 00
          &78 = 36.000MHz, V+ H- (640*350) %01 1110 00
          &B4 = 36.000MHz, V- H+ (720*400) %10 1101 00
          &3D = 25.175MHz, V- H- (640*480) %00 1111 01
          &79 = 25.175MHz, V+ H- (640*350) %01 1110 01
          &7B = 24.000MHz, V+ H- (640*350) %01 1110 11
          &3F = 24.000MHz, V- H- (640*350) %00 1111 11
          &F3 = 24.000MHz, V+ H+ (640*350) %11 1100 11

The second file "UseAcornMd" is the source to a module I wrote based on these results, to select and control the WE super VIDC sync and clock speeds on each mode change - allowing RISC OS built-in VGA/SVGA modes to correctly use the super enhancer - avoiding need for WE mode module.

IIRC the WE software was very clunky. I think it was designed for RiscOS 2 - it certainly didn't support all the RiscOS 3 VGA/SVGA modes - and it contained lots of new mode definitions which were unnecessary on RiscOS 3. So the module I wrote was a much smaller and simpler controller, just to get the enhancer working correctly with all RiscOS 3 SVGA/VGA modes and remove the need for the WE software.

I'll email a copy now, as I still haven't figured the FTP out. Can you upload it?

Steve

[PaulV]

Definitely!

Bits 0 and 1 are confirmed as the clock selection pins.

Bits 2 and 3 appear to be connected to the clock selection circuitry on my board and this concurs with the data in your post.

Bit 4 is a bit of an odd one. It forms part of the Sync. Polarity circuit but your experiments indicate that it does nothing and is always set at 1.

Bit 5 is hard wired on the 36MHz only board to tie it to 0v as the Philips 8574 IIC chip is active low so defaults to all pins being high at power on. It's the presence of Bit 5 or not that determines whether or not its the Standard (36MHz) or Super (25.175MHz and 36MHz) version of the WE VIDC Enhancer.

Bit 5 is always 1 in your experiments so I can determine that you had the Super VIDC Enhancer with both oscillators.

What's odd is that the pins for bits 6 and 7 aren't connected to the Sync. Polarity selection circuit on board. Instead, on the "Standard" board they're simply connected to solder points for wires that go off the the main PCB somewhere...

Pin to bit mapping

Pins-bits.jpg (59.03 KiB) Viewed 16648 times

[PaulV]

I think I've spotted an error in Steve's table... THe H.Sync and V.Sync settings should be as follows.

Code: Select all

        V.Sync  H.Sync  VGA MODE
0       +ve     +ve     -
1       +ve     -ve     VGA 400
2       -ve     +ve     VGA 350
3       -ve     -ve     VGA 480

In Steve's table there are a couple of typo's so here's a corrected version

Code: Select all

                                                 __
                                            HV 11HV CLK
                                            ||   || |
   So far &F0 = 36.000MHz, V+ H+ (800*600) %11 1100 00
          &78 = 36.000MHz, V+ H- (640*350) %01 1110 00
          &B4 = 36.000MHz, V- H+ (720*400) %10 1101 00
          &3D = 25.175MHz, V- H- (640*480) %00 1111 01
          &79 = 25.175MHz, V+ H- (640*350) %01 1110 01
          &7B = 24.000MHz, V+ H- (640*350) %01 1110 11
          &3F = 24.000MHz, V- H- (640*350) %00 1111 11
          &F3 = 24.000MHz, V+ H+ (640*350) %11 1100 11

If someone could have a quick review of this and confirm that'd be good. Also, are the last two row valid? Shouldn't they all be the same as the row directly above them that has a value of &7B or are they experimental values?

Paul

[steve3000]

Hi Paul,
I can't spot the difference in the table you posted (maybe because I'm looking on my iPhone)...

The last two values are correct for my exploration. But whether they are valid for vga modes - almost certainly not - I was just exploring all the combinations of sync and clock speed possible. So it shouldn't say 640x350 - as that won't be selected by any monitor with those sync settings.

Steve

[PaulV]

The error was a typo in the first row. You had it as V+ V+ instead of V+ H+. That and the two bottom rows looked "suspect" to me

Paul

[steve3000]

The error was a typo in the first row. You had it as V+ V+ instead of V+ H+.

Ahh yes, see that now (back on a real computer) - well spotted.

Do you think this will be enough information for you to be confident enough to add sync-setting for the WE super enhancer to AutoVIDC? It would be nice get hold of one of these to fully test though...

Steve

[PaulV]

Yes, it's plenty of info for building in the relevant code.

I've made a start on the SWI code but have hit an anomaly in the data passed in.

If you send &FF on the "standard" version, you get &DF when you read back. This lets you identify the board as "standard".

Now, when setting the clock and sync for 36MHz in MODE 27, I send &D0. I'm expecting to read &D0 back but I see &C0 instead.

I keep going through the code with a calculator to make sure I'm setting everything correctly and it looks good but this one bit is being flipped when I don't think it should be. It's very odd.

Paul

[PaulV]

Just to add to this.

If I run the same experiment in MODE 31 and switch between 24MHz and 36MHz oscillators, I send &1F and &1C respectively and then reading them back they are both correctly set at &1F and &1C.

Obviously the Sync. Polarities are different for MODE 27 and MODE 31.

Code: Select all

        
V.Sync  H.Sync  VGA MODE
0       +ve     +ve     -
1       +ve     -ve     VGA 400
2       -ve     +ve     VGA 350
3       -ve     -ve     VGA 480

MODE 31 MonitorType 4 returns 0 according to the table above and MODE 27 MonitorType 4 returns 3.

So, here's exactly what I'm sending/retrieving in MODE 27. Both -ve V and H sync.

%11010011 (&D3) 24MHz

and

%11010000 (&D0) 36MHz

Here's what I get back...

%11000011 (&C3) 24MHz

and

%11000000 (&C0) 36MHz


For MODE 31 I send and get back the same patterns which are +ve V and H sync.

%00011100 (&1C) 36MHz

and

%00011111 (&1F) 24MHz

It's most puzzling, but looking at this again I think it could be a hardware thing...

I'm going to take another look at the PCB. Perhaps one of the V/H sync bits is physically linked to the bit that is getting flipped. It certainly appears that that is the case and it would cause the anomalous readings explaining all of my results. Looking at the photo there is a 0 Ohm resistor bridging a track in that area of the PCB so that may just be the cause of the phenomenon.

If this theory does prove to be correct, then I've already sorted the Sync. Polarity when using the SWI and I'll have to build it into the main service handler.

Paul

[PaulV]

My theory about the connected pins appears to be correct. pin 7 (bit 3) is connected via the 0 Ohm resistor to pin 9 (bit 4).

There are several resistors and cap's on the PCB that are part of the 36MHz only config and spaces for others that are for the Super version with both oscillators. It appears that the 0 Ohm resistor is one of those config specific components that would not have been fitted to the Super VIDC Enhancer.

As such, whatever is sent as data to bit 3 is immediately replicated to bit 4 regardless of what it is set to itself. This causes the discrepancy in the data I've been seeing and also why the bit is set when sending &FF and why it's not set when sending &D0 or &D3.

So, it seems that I've already implemented the relevant code to set the Sync. Polarity based on the information Steve has provided and the subsequent confusion was based entirely on the fact that the configuration of the PCB causes some data to be overridden by the electrical connections that are or are not made.

That's been a good day wasted chasing ghosts on the bit setting front. Still, it's a good piece of knowledge to have about these little beasties and I can now verify what I send to the board and what I read back knowing that certain bits may be different to what was originally sent.

Paul

[PaulV]

Just to round off this thread, I've released v2.08 to the JASSP FTP server for testing as per this thread.

Paul