(Bush IBX port) Debugging VIDC VIRQ POST test

Hi all,

I’ve been porting the IOMD branch to the Bush Internet TV set-top box as a fun side project. As of this evening I’ve got enough of the IOMD HAL working that it’ll boot. Sadly it fails the VIDC VIRQ self test:

The key difference I should note about the IBX and a RISC PC or A7000, is that the IBX doesn’t have a video VCO. Instead it uses the 32MHz I/O clock (RCLK) for VIDC. This might be related to the test failing…

IOMD HAL init
0000aa7c = IOMD ID
Probe_DRAM_bank
10000000 = bank address
003fffff = decoded address lines
Probe_DRAM_bank
14000000 = bank address
003fffff = decoded address lines
Initialise_DRAM_A7000 done
003fffff = bank 0
003fffff = bank 1
00000000 = bank 2
00000000 = bank 3
00000070 = DRAMWID
POST started
0000cfae = Vsync time
00004051 = POST result

Looking at the code, it seems like I’m getting a Vsync rate of 0xCFAE 2MHz ticks = ~37.62 Hz, which is about half of the ~60Hz (33,333 ticks +/- 2000 ticks) it’s expecting. No surprise that it’s failing the test. The POST test’s measurement is definitely correct — I checked the frame rate of the video output (via the Csync output) using an oscilloscope and got the same number.

I’ve not been able to figure out why I’m getting this specific count (0xCFAE, or 53166 ticks) versus the ‘ideal’ of 33,333. It seems to be about 1.6x slower. That doesn’t match up with the ratios of any of the clocks in a RISC PC or A7000 that I know of, versus the Bush box (which has a 48MHz and a 64MHz crystal). There’s provision to fit a HCLK (video clock) crystal at X3 (R32 must also be fitted) and a SCLK (sound clock) crystal at X2 (also fit R20) but neither of these are fitted in my box. Can you say cost-optimised? :)

I had a dig in the old NC branch (https://gitlab.riscosopen.org/RiscOS/Sources/Kernel/-/blob/d068e40f3492db08248eb47be6c33df69c53b640/TestSrc/Begin) and noticed that the VIRQ test doesn’t run on ARM7500FE systems:

; 15-May-96	BAR	2.06	Update for ARM7500FE variant, new IOMD ID
;				Code. Used initially in the NC product;
;				needs different prescalers and ROM speed
;				settings, switched on IOMD ID code.

; 24-Jun-96	BAR	2.10	Updated second check on IOMD ID, instead of
;				checking for ARM7500 IOMD ID code to skip
;				the Virq test, now checks for the original
;				(RiscPC) IOMD ID code and skips Virq test if
;				not equal. Thus ARM7500 and ARM7500FE
;				devices don't execute the test.
;				Updated version number.
;				Added call to sir_IOMD_Regs -show iomd registers

 [ MorrisSupport
        MOV     r3, #IOMD_Base
        LDRB    r1,[r3,#IOMD_ID1]	; load r1 with IOMD ID high byte
        LDRB    r0,[r3,#IOMD_ID0]	; load r1 with IOMD ID low byte
        ORR     r0,r0,r1,LSL#8		; Or r0 and r1, shifted left 8, put in r0
        LDR     r1,=ts_IOMD_ID1		; get Ref IOMD ID code #1 (Original)
        CMPS    r0,r1                   ; check for IOMD ID Code #1
	BNE	%FT10			; If not equal, got to 10
					; thus skip Virq test on ARM7500 and ARM7500FE (Morris)
 ]

For now I’ve pulled this into my branch but checking the “STB” flag instead of “MorrisSupport” — but I was wondering if anyone knew whether this is the right way to go?

I feel like a more correct fix would be to work out why the VIDC is initialised wrongly, and fix VIDCTAB so that it produces the correct video signal (PAL or NTSC?), then fix the Virq test.
I’ve had a look at the video section of the CL-PS7500FE datasheet but it seems a bit light on the details (or more likely I’m looking at the wrong part of it) and I’ve not been able to figure it out.

Anyway, questions aside — if anyone’s interested in trying out this absolute insanity…

1. Check out the main IOMD build Git repo
2. For each repository in the list below:
   1. Use “git set-url” to change the URLs (see list)
   2. git pull
   3. git checkout philpem_add_bushibx
3. Build as usual (Builder, prepare, build, etc)

Repos:

• BuildSys: https://gitlab.riscosopen.org/ppemberton/BuildSys
• Env: https://gitlab.riscosopen.org/ppemberton/Env
• ADFS: https://gitlab.riscosopen.org/ppemberton/ADFS
• HdrSrc: https://gitlab.riscosopen.org/ppemberton/HdrSrc
• Kernel: https://gitlab.riscosopen.org/ppemberton/Kernel
• FPASC: https://gitlab.riscosopen.org/ppemberton/FPASC
• HAL_IOMD: https://gitlab.riscosopen.org/ppemberton/HAL_IOMD
• VIDC20Video: https://gitlab.riscosopen.org/ppemberton/VIDC20Video

Be warned, you’ll ideally need to use 27C322 ROMs – primarily because this is an 8MB ROM. If you want to use 27C160s in a Bush set-top, you’ll have basically no application space, but also you need to stack two 42-pin IC sockets for each ROM. Pop the /BYTE pin (I think it’s pin 22?) out of the bottom socket. Clip the leg back on the top socket and wire /BYTE to VCC. This pin is wired to A22 on the motherboard… as soon as RO tries to boot, it’ll switch the ROM into byte mode and start getting garbage from it.

You’ll also need to disable the SerialDeviceDriver as that crashes the box on boot. The CMOS apparently resets on every boot and ADFS hangs for quite a few seconds. But that’s all on my buglist and something I can fix later.
I’ve no idea what’s going on with the SerialDeviceDriver — I enabled debug for it and got no output — but the ADFS hang is probably related to the CMOS stuff, likely looking for an IDE hard drive then timing out.

I don’t have an IBX box so can’t immediately assist with your VIDC clock question, but I’ll chip in with a few minor comments:

BuildSys, Env, ADFS, Kernel, FPASC – all look like the usual steps involved with adding a Machine type, no excitement there. I’d probably question what ADFS is doing in the ROM given the IBX doesn’t have a floppy drive or harddisc, unless you’re planning some hardware butchery to add them.

HdrSrc – we shouldn’t be advocating reintroducing assembly time hardware selections, such switches shout “that’s not hardware abstraction” to me, they belong in the HAL component rather than a global header file.

VIDC20Video – likewise, assembly time hardware selections don’t belong here. The VCO option was hardwired just because of the origin of the source code to this module as a way to kick the can down the road since it was known STB support wasn’t needed. Such things belong in the HAL too, though that could be as simple as signalling that option through the HAL device, the key bit being that there’s only 1 VIDC20Video module rather than lots of different ones depending on assembly/compile time decisions.

HAL_IOMD – it’d be nice if there was some way to distinguish an A7000+ from a Bush IBX, does the SMSC’669 have a different chip ID to the ‘665 for example? Or a peek of the podule bus to spot the modem? For the VIDC POST failure, yes, the sensible thing to do is work out why the 60Hz VGA settings didn’t result in a 60Hz flyback interrupt rather than ignoring the failure.

Thanks for the comments.

ADFS (and the Econet modules etc.) are in the ROM despite the lack of appropriate hardware because I haven’t fettled the ROM build files yet. I need to include the Zip Drive drivers, but I want to get a star-prompt (over serial) first, then bring up the other hardware.

Having the option of including ADFS would be good but as you say it requires hardware butchery. IDE is possibly the only mod with any real point (using some variant of Vectorlight’s A3010 IDE mod) but it’s still a mod. The TTL serial port is at least a fairly easy mod with only three wires needed!

Re the hardware-specific mods, the 669 is one way of detecting the Bush box. The HdrSrc changes only affect the HAL anyway – so they could feasibly be moved into the IOMD HAL source. That’s going to change by definition with any machinetype anyway.

Distinguishing the hardware is possible – the SMC 669 does have a different chip ID, and you can see that in the IOMD HAL source. My updated init code checks for a 669 and uses a different init process which the 669 needs (its I/O addresses are programmable and there are no sane defaults).

I’m just not sure of the best way to pass the “machine is a Bush IBX set-top” flag back ‘up the chain’ to other parts of the OS, then check it in e.g. VIDC20Driver to set things like the VCO mode — but also later down the line, the default video mode.

At the moment my build is set up for HAL debug and DebugTerminal, and gets as far as the SerialDeviceDriver loading before crashing unceremoniously. (I’ve just read that out loud and realised that it might not be crashing, but SerialDeviceDriver might be reconfiguring the serial port and killing the DebugTerminal). Video output seems to be separate-sync VGA, but I need PAL composite-sync. All stuff I need to look into…

ADFS (and the Econet modules etc.) are in the ROM despite the lack of appropriate hardware because I haven’t fettled the ROM build files yet.

Fair enough, I thought your module list was based on what *ROMModules had told you from the IBX’s mask ROM which is why ADFS’ presence looked a bit odd.

I’m just not sure of the best way to pass the “machine is a Bush IBX set-top” flag back ‘up the chain’ to other parts of the OS, then check it in e.g. VIDC20Driver to set things like the VCO mode — but also later down the line, the default video mode.

As you say the HAL could select at assembly time, but my bet is it’s 98% the same as an A7000+ so could do some detection and put a value into IOSystemType to deal with the last 2% of differences. Whatever detection method only needs to be certain it’s not a Risc PC/A7000/A7000+. Say we went with the ‘669 ID register – that does the job, and if someone comes along in 2 years wanting to add another variant which also uses the ’669 that’s their problem to differentiate!

For video specifically, you can force the default mode with GraphicsV 16 so then all that’s needed is a way to signal from the HAL that it’s not a Risc PC/A7000/A7000+. The Video device API is a bit of an untamed beast because nobody’s ever put in the hours to design a proper API which covers the plethora of different video controllers, so in practice once you’ve found the one you know about (HALDeviceID_VDU_VIDC20) you could

• append some functions to the HAL descriptor
• just use the devicespecificfield as a 32 bit bitmask to say something
• push the boat out and define a whole new video device type and write a new module driver IBXVideo

(I’ve just read that out loud and realised that it might not be crashing, but SerialDeviceDriver might be reconfiguring the serial port and killing the DebugTerminal)

Yup. Take a look at the debugging guide which recommends knocking out the ROM serial drivers if you’re trying to use the same UART for HAL debug. Some boards have loads of spare UARTs so can set aside one for HAL debug and present the rest for OS_SerialOp but not in your case.

Yup. Take a look at the debugging guide which recommends knocking out the ROM serial drivers if you’re trying to use the same UART for HAL debug. Some boards have loads of spare UARTs so can set aside one for HAL debug and present the rest for OS_SerialOp but not in your case.

D’oh – that makes sense. Sadly the module it recommends knocking out (DualSerial) isn’t in the Components file for IOMD builds, so I’m not 100% sure what I need to disable.
It seems like the HAL doesn’t expose the UART using the UART HAL entries.

Regarding the video driver, I don’t think there’s really a need to have a completely separate video device driver. There’s a lot of commonality between “VIDC20”, “VIDC20 in an ARM7500 or FE”, and “VIDC20, in a 7500FE, in a Bush set-top”. It’s really just whether we use RCLK or VCLK instead of a VCO, and whether the driver should default to generating PAL and/or NTSC instead of VGA.

My current to-do list looks like this:

 - **Components file**
    - :?: Temporarily disable the `SerialDeviceDriver`
  - **HAL_IOMD**
    - Add a new `IOSystemType`, e.g. `IOST_7500_BushIBX`
    - `s.Video`: Check the `IOSystemType`. If it's `IOST_7500_BushIBX` then...
      - Set a bit in the VIDC20 device-specific field to indicate the VCO type is -- whatever it needs to be.
        - (this might need defining somewhere in HdrSrc, so both the @VIDC20Driver@ and @HAL_IOMD@ have a common definition)
  - **HdrSrc**
    - Move `FECPUSpeedNormal` and `FECPUSpeedHalf` definitions into `HAL_IOMD`. (this keeps hardware-specific stuff out of the headers)
  - **VIDC20Driver**
    - Check the device-specific field and act accordingly, e.g. VIDC clock is HCLK/RCLK-only
    - If device-specific field requests PAL modes, use PAL video mode tables from the NC branch
  - Write an RCMM keyboard and mouse driver
  - `HAL_IOMD.s.RTC` (and whatever calls it): the Bush box has no RTC
    - Check NC branch to see what was done to add Serial EEPROM support.
    - Read system configuration from NVRAM instead of the RTC.

p.

I’ve also noticed that this is 90% of the way to something that’d run on the NC family – the main missing part would be whatever IR keyboard support is needed there, and support for the Chrontel composite video chip. Oh, and a network or modem driver. I doubt anyone’s as mad as I am though, so I don’t expect it’ll happen.

Is the Serial module in there if so remove that.

There are 2 Serial modules ‘Serial’ and ‘Dualserial’

The only serial modules in the Components file are:

SerialDeviceDriver
SerialDeviceSupport
SerialMouse

For my next build I’ve disabled all three…

Sadly the module it recommends knocking out (DualSerial) isn’t in the Components file for IOMD builds

As Colin mentions it’s Serial, as in the component whose sources are in RiscOS/Sources/HWSupport/Serial, but don’t forget the ModuleDB gives things friendly names, which in this case is SerialDeviceDriver. SerialDeviceSupport (which points at RiscOS/Sources/HWSupport/SerialSpt) just provides a bit of BBC Micro-esque emulation, you could leave that in since it doesn’t poke registers itself, and SerialMouse goes via DeviceFS/SerialOp so also doesn’t poke registers. But I’ll admit I usually just comment out the whole group that start with the word “Serial” too.

DualSerial’s a bit of a misnomer too. It’s really PolySerial as it definitely supports more than 2 ports.

Set a bit in the VIDC20 device-specific field to indicate the VCO type is – this might need defining somewhere in HdrSrc, so both the VIDC20Driver and HAL_IOMD have a common definition)

The definition of the VDU HAL device is in the Kernel as it happens. You’d probably need to conjure a define with VIDC20 specific name space to make it clear. As I said earlier the VDU HAL device isn’t very well thought out.

`HAL_IOMD.s.RTC` (and whatever calls it): the Bush box has no RTC

Yes, it’s mildly inconvenient the Philips RTC has a base address of &A0 as does most of the world’s EEPROM. The HAL RTC just needs to return “no”, but the HAL NVRAM will need to declare whatever EEPROM there is (or at least the first 256 bytes of it). If that can’t be done with IIC probing, since it’s the HAL and you already figured out you’re an IBX200, they could just switch on IOSystemType there.

It looks like removing the Serial modules was the answer, as the Bush box just booted to its first 32-bit star prompt:

init mod DHCP
init mod !Edit
init mod !Draw
init mod !Paint
init mod !Alarm
init mod !Chars
init mod !Help
init mod PortManagerError: DataAbort:Abort on data transfer at &FC3A5868 (Error Number &80000002)
*.

Directory '@' not found (Error number &D6)
*resourcefs
*.
Dir. Resources:$ Option 02 (Run) 
CSD  Resources:"Unset"
Lib. Resources:"Unset"
URD  Resources:"Unset"
Apps         DWR/    Fonts        DWR/    Resources    DWR/   
ThirdParty   DWR/   
*

The data abort in PortManager is a weird one.

The address is obviously in ROM (*Where confirms that), and the ROM map in the build log says it’s in the PortManager code.
Working backwards from there I pinned it down to c.module (after telling link to display the map, and messing around with DecAOF) — but couldn’t pin it down to a function.
After that I rebuilt PortManager with the “-g” option and rebuilt the ROM, which at least gave me debug-enabled object files with line-number references.

I’ve done a bit of debugging on the box, and landed on this:

init mod PortManagerError: DataAbort:Abort on data transfer at &FC3A5D68 (Error Number &80000002)
*where &FC3A5D68
Address &FC3A5D68 is at offset &003A5D68 in ROM
*ShowRegs
Register dump (stored at &2000CDF0) is:
R0  = 03200000 R1  = 23CCF468 R2  = 2007567C R3  = 000000FF
R4  = 00000000 R5  = FC00EC14 R6  = 3000352C R7  = 00000000
R8  = 23CCF468 R9  = 3000352C R10 = FA20021C R11 = FA207EF4
R12 = FA207EA4 R13 = FA207EA4 R14 = FC3A5C9C R15 = FC3A5D70
Mode SVC32 flags set: nZCvqjggggeaift        PSR = 60000013
*MemoryI &FC3A5D58
FC3A5D58 : ...� : E51A1218 : LDR     R1,[R10,#-536]
FC3A5D5C : . �� : E0812000 : ADD     R2,R1,R0
FC3A5D60 : 2.�� : E3A00632 : MOV     R0,#&03200000
FC3A5D64 : .0�� : E5923008 : LDR     R3,[R2,#8]
FC3A5D68 : .0�� : E580300C : STR     R3,[R0,#12]

After some more calculating of offsets and dumping object files with Decaof (there has to be an easier way…) I found that this assembler code maps to this line of code: https://gitlab.riscosopen.org/RiscOS/Sources/HWSupport/PortMan/-/blob/master/c/module#L340

I can’t figure out why the write to IOMD_CLINES is causing a data abort, especially in SVC32 mode… the IOMD can’t have moved, and in SVC mode there should be essentially no memory protection. Very odd.

As Colin mentions it’s Serial, as in the component whose sources are in RiscOS/Sources/HWSupport/Serial, but don’t forget the ModuleDB gives things friendly names

Ah! I didn’t realise that. As in, I noticed the source code wasn’t where I expected it, but didn’t realise ModuleDB was how that was handled.
I’m used to working on the 3.71 codebase, the ROOL branch is oddly familiar (the Components and Env stuff for instance) but things like ModuleDB are a nice reminder that it’s moved on a bit since then.

I’ll have to take a closer look at the SerialDeviceDriver at some point anyway, as the RCMM keyboard is tied to the second serial port and will need to talk to it.

MOV R0,#&03200000
I can’t figure out why the write to IOMD_CLINES is causing a data abort, especially in SVC32 mode… the IOMD can’t have moved,

Oh yes it can! IOMD’s physical address hasn’t changed, but its logical address certainly isn’t at &3200000 any more – that’s now somewhere near the bottom of RISC OS 5’s 512MB application slot (and probably not mapped in if you’ve only got an 8MB SIMM).

PortMan looks like it’s in a bit of a sorry state, having had some other STB support grafted onto it in 2004, but that also just merrily peeks magic memory locations. I suppose it predated the HAL GPIO device so didn’t have much choice, but those chickens have come home to roost now you want to awaken the 7500FE code path after 21 years of peaceful sleep.

I’m not sure what PortMan brings to the party so would suggest a 3 step plan:

• It’s not life critical so just knock it out of the ROM for now and do something more important first
• At least update it to discover the logical address of IOMD
• Consider permanently removing it later and doing something via the HAL instead

I’ve actually got it fixed – I may have pushed the patched code to Gitlab not long before you posted.

PortMan is a GPIO manager, it provides SWIs which applications and modules can use to turn hardware on and off. As you say, someone’s grafted on support for a Conexant set-top box processor which had PCI. The 7500FE obviously doesn’t, so the wag who added Conexant support clearly decided to use that as the differentiator… in this post-HAL world, it probably should have asked the HAL what hardware it was running on.

I’ve added some code to the ARM7500FE path to make it grab the IOMD base address using OS_Memory 9, which seems to work.

That revealed another bug in PortManager – a “Buffer overflow” error at the end of initialisation.

It turns out that PortManager loads the GPIO definitions from a file called ResourceFS:Resources.PortMan.Tags. That file is parsed using MessageTrans (so it has the usual Tag: arbitrary text value format), which also means there’s a maximum length a tag can be. That’s defined in the code as 16 characters. Well, “Front_Panel_Button” is 18 characters, so that wasn’t going to work. On RO3.71, MessageTrans doesn’t really care, but RO5 is a mite less trusting of such silliness. I’ve bumped the limit up to 24 characters, which should be enough for any reasonable

The NVRAM module is complaining that it can’t find its Tags file — which is correct, there isn’t one in the repository for the “Lazarus” platform. I’ll have to copy it out of the Bush NCOS ROMs if I need it. Thing is, that module is used to store user configuration outside of the RISC OS ‘CMOS’, so it’s only really used for storing things like the dial-up phone number. I doubt it’ll be of much use… It’s still a useful feature from the land of NC builds though, if only to store tiny bits of config in the 32Kbit EEPROM.

I’ve noticed that when the Desktop starts, I lose the serial port output. That’s a bit annoying — so to try and stop it, I commented out the Desktop module in the Components file. Imagine my surprise when the Desktop still tried to start! I’m not sure what was going on there, but given the NVRAM still wasn’t working (as I’d mistyped LDRB as LDR), it was easy enough to change the DefaultCMOSTable in Kernel.s.PMF.i2cutils to set Language to zero (vs. the default of 11). I’m not sure what I would have done had that not worked.

This one’s got me puzzled. Here’s a block of code I’ve added to HAL_IOMD.s.Boot:

        LDRB    ip, IOSystemType        ; What I/O system type is this?
        CMP     ip, #IOST_7500          ; First check for Bush IBX STB
            ; condition EQ here means ARM7500 or ARM7500FE
        LDRBEQ  ip, ComboChipDeviceID   ; What combo chip is installed?
        CMPEQ   ip, #CCDID_SMC_669      ; is it a 37C669?
            ; condition EQ here means 7500 processor with a 669, likely a Bush IBX
        MOVEQ   ip, #IOST_7500_BushIBX  ; If it is, change the system type to Bush settop
        STRBEQ  ip, IOSystemType

When I build this, I get a “Warning: UAL syntax in pre-UAL A32 code” warning from Objasm, on the “LDRBEQ” and “STRBEQ” lines.

It’s only a warning and not an error, but is this anything to worry about?

Just use ye olde LDREQB syntax.

That’ll teach me to use the ARM website as a reference guide for instruction syntax! I completely forgot about the old syntax that had the condition code before the byte qualifier…

(This is quite long, again… purposely, as I’m trying to get all this documented for anyone mad enough to try and do a settop port in future… there’s a summary at the end)

Righto, starting on the video driver now. (and this is likely to lead to the

The current state of play is – video is being generated, but it’s with separate syncs and likely whatever the default mode it’s detected is. MonitorType is Auto, so the kernel and HAL are probably trying to sense the monitor type from the ID pins, which isn’t going to work very well because a TV on a SCART port doesn’t have them.

Monitor type translation is left down to the kernel. This is done by TranslateMonitorLeadType in Kernel.s.PMF.osinit, which calls Service_MonitorLeadTranslation if it’s claimed. If it’s not, it reads the MonitorLeadType variable and looks it up in MonitorLeadList (same source file).

This is the standard list:

MonitorLeadList
        ; KJB - changed default modes to 256 colours
        MonitorLeadItem 4_3330,  28, 3, 0                       ; VGA-capable monitors
        MonitorLeadItem 4_3111,  28, 5, 0                       ; Nothing - try LCD (fudge fudge)
        MonitorLeadItem 4_3333,  15, 0, 1                       ; Others - assume TV standard

The parameters are (from left to right):

• Monitor ID lines, 0/1 for low/high, or 3 for don’t-care.
• Default screen mode
• Monitor type
• Sync type (0 for separate syncs, 1 for composite)

On the NC branch, if STB = TRUE, assuming there’s no PAL/NTSC selection pin, then there’s only one entry in the list:

        MonitorLeadItem 4_3333,  12, 0, 1                       ; PAL TV assumed

Or if there is a PAL/NTSC bit:

        MonitorLeadItem 4_0333,  12, 0, 1                       ; PAL TV
        MonitorLeadItem 4_1333,  46, 8, 1                       ; NTSC TV

The obvious way to fix this is to claim Service_MonitorLeadTranslation and return either PAL or NTSC as appropriate. To me, the obvious place seems to be the PortManager. The only thing I’m not clear about is how to force a RISC OS mode change if the PAL/NTSC selection has changed — but perhaps that’s not a good idea as PAL and NTSC have different video resolutions.

Digging deeper, the code for actually reading the monitor type bits lives in the VIDC20Video driver now. VIDC20_Init (in s.VIDC20Video) calls DetectMonitorID (in s.MonitorID), then stores the result in IdentityBits.
DetectMonitorID reads the monitor ID bits – on a RISC PC only ID0 is available, and it’s read from the “mouse button and monitor ID buffer” that’s gated by the S1rd* signal.
On anything else, it uses the IOMD C-lines on the 7500/FE chip.

As things are, I’m not even sure that the ARM7500/FE systems (A7000/A7000+/Odyssey) have more than ID0 connected to the 7500 chip’s “CLINES” 8-bit I/O port… I don’t have a motherboard to check, and I don’t think there’s a schematic available outside of Acorn, circa 1997, when the workstation division was shuttered.

Wrapping all this up:

• DetectMonitorID needs to check the Device Specific Field the HAL passed in the VIDC20 descriptor. If the “output device is a TV” flag is set, it needs to force the ID bits to “TV”.
• Something needs to check whether it’s running on a Bush IBX box, and if so:
  • Claim Service_MonitorLeadTranslation to…
    • Check the GPIOs
    • Pass back appropriate values (default mode, sync, etc for PAL or NTSC) to override TranslateMonitorLeadType.
  • On start-up, read the GPIOs, apply that monitor type, and tell RISC OS to change to the default mode. (As the Kernel probably defaulted to PAL and we want NTSC, or vice versa)
• Whatever the “Something” is, will probably have a dependency on PortManager to access the GPIOs.

I also noticed that VIDC20Video.s.Modes made assumptions about the VIDC clock:

        LDRB    r1, IsMedusa
        MOVS    r1, r1
        LDRNE   r1, =24000              ; Medusa => 24MHz oscillator
        LDREQ   r1, =32000              ; Others => 32MHz oscillator
        LDR     r0, [r4, #VIDCList3_PixelRate]
        BL      CalculateVCO

So this might need some changes too. Otherwise it might explain why the Virq test is failing: because the clock config register setting is for a 24MHz oscillator and VCO, while the 7500FE uses 32MHz.

Just having a quick look at the VIDC20 Virq test. I think I can see why it’s failing.

First I need to explain the “VCO start fix”. This doubles the frequency of the VCO, then applies a divide-by-two prescaler in the VIDC. For some reason this makes the VCO more reliable?

The comments in HAL_IOMD.s.Video say that on a RISC PC with VCO VIDC clock, the final clock is 50.4 MHz / 2 = 20.2 MHz. On an ARM7500/FE system it’s 50.286 MHz / 2 = 25.143 MHz

Moving up the code to the register settings:

        DCD     &80000318               ; HCR + 8 = 94 + 22 + 22 + 640 + 22 + 0 = 800
        DCD     &9000020B               ; VCR +2 = 2 + 32 + 0 + 480 + 0 + 11 = 525

Plugging these numbers into a calculator, we can figure out the interrupt rate:

Frame rate = Fvidc / HCR / VCR
Frame rate = (50.4e6 / 2) / (0x318+8) / (0x20B+2)
Frame rate = 25.2e6 / 800 / 525
Frame rate = 60 Hz.

Or with the ARM7500/FE’s 50.286 MHz VCO clock:

Frame rate = (50.286e6 / 2) / (0x318+8) / (0x20B+2)
Frame rate = 25.2e6 / 800 / 525
Frame rate = ~59.8643 Hz.

The Virq test measures against a 2MHz clock so for these we should see results of:

Nticks = 2.0e6 / frame rate
Nticks = 2.0e6 / 60      Hz = 33,333 ticks
Nticks = 2.0e6 / 59.8643 Hz = 33,408 ticks

The Virq test will accept anything from 32,333 to 34,333 ticks, so both the above are fine.

When it fails on the Bush box, it reports a count of &CFAE = 53,166 ticks = 37.618 Hz

The problem arises when we switch to the RCLK clock:

    [ VIDCClockSource = "RCLK"
        DCD     &E0000406               ; CR: FIFO load 16 words, 1 bpp, ck/2, rclk
    ]

On the ARM7500FE systems (A7000, Bush IBX), RCLK is 32MHz, divided down from a 64MHz crystal. The VIDC RCLK input is the 32MHz I/O clock, and we have the divide-by-two prescaler enabled too.

Frame rate = (32.0e6 / 2) / (0x318+8) / (0x20B+2) = 28.5714 Hz
Tick count = 2.0e6 / ( (32.0e6 / 2) / (0x318+8) / (0x20B+2) ) = 52,500 ticks

But what if we turn off the prescaler?

Frame rate = (32.0e6 / 2) / (0x318+8) / (0x20B+2) = 76.190 Hz
Tick count = 2.0e6 / ( (32.0e6 / 2) / (0x318+8) / (0x20B+2) ) = 26,250 ticks

That’s a little closer to 33,333 but it’s still out of range. I don’t think there’s a way to generate the 640×480 1bpp mode from the clock frequencies we have available to us, without editing the mode definition.

Meanwhile I’ve spent half the evening trying to figure out why I couldn’t access the module workspace (specifically the device-specific flags in the descriptor) from CalculateVCO.
It turns out CalculateVCO corrupts R12, the workspace pointer…. I’m pleased to say it doesn’t any more!