S-video build for Beagle?

Quoting myself:

flash the user LED to the left of the power socket off and on once per second, and possibly to flash the user LED next to the microSD

My bad. The User LEDs appear to be the ones either side of the microSD location. It pays to only look at schematics after the third mug of tea… ;-)

Hi Jeffrey,

On your post of May 18, 2012 2:04am, you linked to a build of RISC OS that supported s-video. Is it still the case that a special build is required?

If this is so, would it be possible to include this code in the main releases – perhaps using the configuration of MonitorType 0 (that’s TV-monitor, yes?) to select if s-video should be used in preference to DVI/HDMI?

Best wishes,

Rick.

Is it still the case that a special build is required?

Yes, that’s still the case.

Since uploading that build I have fixed the two main bugs with the TV-out (mouse pointer not always being in right place, and corrupt display when using big modes), so the code’s probably in a good enough state to be enabled in normal builds. The trouble is, I can’t decide on how the OS should decide when to have TV-out enabled, and whether to go for a PAL or NTSC signal. It’s not quite as simple as looking at the configured monitor type, as (I think) you’re only able to use modes defined in an MDF if you have it set to monitor type 7!

How about this for a solution: The OMAP supports TV detection, so on startup it’ll use that to decide whether to use the TV-out or not. For the choice of PAL or NTSC (or various PAL/NTSC variants) it’ll look at your configured territory. This way we can put off worrying about CMOS flags and other things until later.

By the way, I think I’m about halfway towards understanding how to program custom video timings for the TV-out. When I next get some free time maybe I’ll have a go at plugging in some values and seeing if I can get things to work.

Is it still the case that a special build is required?
Yes, that’s still the case.

Ah, so currently no use downloading the builds on the site for those with less fancy setups.

[can textile do quotes-in-quotes?]

(mouse pointer not always being in right place,

Oh, right – I thought I noticed this happening, but didn’t play enough to note it as a definite bug.

and corrupt display when using big modes

Do you mean the display itself screwing up, or the inverted colours?

The trouble is, I can’t decide on how the OS should decide when to have TV-out enabled, and whether to go for a PAL or NTSC signal. It’s not quite as simple as looking at the configured monitor type, as (I think) you’re only able to use modes defined in an MDF if you have it set to monitor type 7!

Eh? Surely only being able to use an MDF in monitor type 7 is a bug in itself? Though, I personally think the quickest “patch” would be to support MDFs in monitor types 0 and 7 (the others don’t really make much sense any more).

How about this for a solution: The OMAP supports TV detection,

What, it can tell if something is plugged into s-video?!?
I’d look in the datasheet, but it’s a little overwhelming.

For the choice of PAL or NTSC (or various PAL/NTSC variants) it’ll look at your configured territory.

Seems logical enough. It looks (at a brief look at a map) that it is northern America, west south America, Japan, India, and a bunch of islands (Philippines?) that were lumbered with NTSC. Everybody else ought to be able to use PAL. I’m not sure of the situation in Russia, though I know that most SÉCAM TVs in France since the late ‘80s have been dual-standard. This was necessary as digital video products (set top boxes, sat receivers, DVD players, games consoles) generally only output PAL or NTSC. I’ve got a variety of things here, not a one of them outputs SÉCAM. Neither does the Beagle. ;-) So with luck, the SÉCAM countries can be considered PAL compatible.

By the way, I think I’m about halfway towards understanding how to program custom video timings for the TV-out. When I next get some free time maybe I’ll have a go at plugging in some values and seeing if I can get things to work.

Great. I’ll look forward to trying it when I get some hardware again.

I do have one (minor) request. Would it be possible to tweak RISC OS to work in an anamorphic mode? My video setup is set in such a way that it is assumed that a full display is 720×576 pixels (PAL standard), but that it is 16:9 aspect. This means everything “widescreen” is stretched in height instead of being offered with black bars at the top and bottom. Better resolution of the end product. Take a look at the two cine film pictures at http://en.wikipedia.org/wiki/Anamorphic_format to see what I mean.

Or… Here’s what RISC OS outputs:
http://www.heyrick.co.uk/random/beagle_full.jpeg
and here’s how I see it:
http://www.heyrick.co.uk/random/beagle_wide.jpeg

Thus, video output from the Beagle is displayed in 16:9 proportions, so the display aspect is slightly off. Can RISC OS support modifications to the eigen values to make this work?

Not an important thing, mind you. It’d just be nice if it was possible/easy. ;-)

Either way, your work on this has been great. THANK YOU!

Best wishes,

Rick.

[can textile do quotes-in-quotes?]

When I need to do this I usually just cheat and use HTML blockquote tags!

and corrupt display when using big modes

Do you mean the display itself screwing up, or the inverted colours?

The display screwing up. Although sometimes I also had it flickering with inverted colours, so maybe that’s fixed too?

The only colour bugs I know of at the moment are:

• Red/blue being swapped in 24bpp modes
• Everything being wrong in 16bpp modes

Neither of which can be fixed without teaching RISC OS about new pixel formats (or implementing a software layer to trap screen reads/writes and convert to/from the right pixel formats). Note that the DVI output doesn’t suffer from these problems because that hardware has a couple of extra features (colour phase rotation matrix & gamma table) which allows the colours to be remapped in hardware without any (major) problems.

The trouble is, I can’t decide on how the OS should decide when to have TV-out enabled, and whether to go for a PAL or NTSC signal. It’s not quite as simple as looking at the configured monitor type, as (I think) you’re only able to use modes defined in an MDF if you have it set to monitor type 7!

Eh? Surely only being able to use an MDF in monitor type 7 is a bug in itself?

No, it’s by design. Monitor type 7 was created as the “use an MDF” monitor type.

Thus, video output from the Beagle is displayed in 16:9 proportions, so the display aspect is slightly off. Can RISC OS support modifications to the eigen values to make this work?

Unfortunately RISC OS only understands eigen values that are integers, which get applied as a binary shift (i.e. pixels = OSunits >> eigen). If we used the hardware display scaling then we could tweak the aspect ratio to whatever you like, but (a) I haven’t implemented suport for it yet, and (b) it’s not available with palettised modes (so you’d be stuck with the somewhat broken true-colour modes).

(or implementing a software layer to trap screen reads/writes and convert to/from the right pixel formats)

As a quick fix, that might be the most suitable option. I would imagine that the number of s-video users vs the number of DVI users is quite small.

On the other hand, would RISC OS have a need to know about different pixel formats for future hardware?

which allows the colours to be remapped in hardware without any (major) problems.

Strange that it is output-specific rather than “the video controller does this”.

Unfortunately RISC OS only understands eigen values that are integers,

Sad, but I have to concede that 16:9 kit didn’t exist back in the mid 80s. ;-)

How do people use modern LCD monitors with RISC OS/DVI? Are they all 4:3 or does everybody just accept that the aspect is incorrect?

Damn. I gotta get me a desk cleared off and the newer compiler tools to look to doing some real stuff.

• I’m horrified at the idea that the USB driver pokes mouse scroll events as wimp messages. This to me is high octane nightmare fuel.
• There’s other stuff, but I will keep this to myself until I feel I am in a position to actually attempt to implement some of it [i.e. one requires a fair amount of Wimp hacking (yikes!) – don’t worry, it’ll be a private build ‘til I’m damn sure it actually works!]

I think next on the list, following the devkit, would be the shockingly pricey JTAG – I can see that would be invaluable for debug. Can you tell me, please, Jeffrey, if I mod the Wimp and it crashes at some point, I can set a breakpoint via JTAG, yes? [please say yes!]

Best wishes,

Rick.

On the other hand, would RISC OS have a need to know about different pixel formats for future hardware?

Yes. Even the Iyonix has trouble with red/blue being swapped! Originally Castle worked around the issue by modifying the graphics cards. But this fix wasn’t applied to the FX-series cards which were released later on. In 24bpp modes this was fine (I think the FX cards can swap the red/blue channels themselves), but for 16bpp modes you end up with red and blue being swapped :(

How do people use modern LCD monitors with RISC OS/DVI? Are they all 4:3 or does everybody just accept that the aspect is incorrect?

The aspect ratio with LCD monitors is usually fine, because they all have square pixels. The only time the aspect ratio would be wrong would be if you’re not using the monitors native resolution (or a mode with the same aspect ratio as the native res), and the monitor doesn’t have an option to scale the view while keeping the (square pixel) aspect ratio intact.

Remember – it’s not the monitor aspect ratio that’s the problem, it’s the aspect ratio of the individual pixels.

I think next on the list, following the devkit, would be the shockingly pricey JTAG – I can see that would be invaluable for debug.

Having JTAG certainly makes some tasks a lot easier, but there are only a handful of situations in which I’d say it was actually invaluable.

Can you tell me, please, Jeffrey, if I mod the Wimp and it crashes at some point, I can set a breakpoint via JTAG, yes? [please say yes!]

Yes you can. Code breakpoints, data breakpoints, breakpoints on processor vectors, etc.

Quick request – Jeffrey – could you (if you have time) make up a build of the latest version that works on s-video? Thanks!

I’ve done one better than that; I’ve now implemented the TV detection code that we talked about earlier. So with any luck, tomorrow’s ROM should boot up fine for you.

Nice. I’ll pick up a ROM image for the weekend.

If, for any reason, it does not detect correctly (I’m feeding the s-video into a USB video capture device, it might behave a little differently), how would I force s-video? Wasn’t there a command like *TVOut?

I do have one (minor) request. Would it be possible to tweak RISC OS to work in an anamorphic mode? My video setup is set in such a way that it is assumed that a full display is 720×576 pixels (PAL standard), but that it is 16:9 aspect. This means everything “widescreen” is stretched in height instead of being offered with black bars at the top and bottom.

Wouldn’t outputting 1024×576 give the desired result? (Assuming the screen isn’t native 720).

(RISC OS 3 had mode 24, 1056×256, which could correspond to a wide screen format)

I’ve now implemented the TV detection code that we talked about earlier.

Follow-up… got myself the official test build of today, installed, it seems to work.

There is one quirk, however – if I ^ShF12 to shutdown, and then click on “Restart”, I get “Application may have gone wrong [blah blah]”.

At this point the mouse pointer is frozen and the keyboard non-responsive, however BeagLEDs LED still blinks so some stuff is still functional.

[see two posts below…]

Beagle xM. RISC OS 5.19 (19-Jul-12).

The revised video code has the screen slightly off the left. To (mostly) correct this, set the following in the 720×576 Beagle PAL def:
Frame rate – 32600 (75Hz)
Sync width – 0
Back porch – 0
L/T border – 12
Display – 720
R/B border – 0
Front porch – 0

The right side is slightly blurry. I’ll need to look in more detail at what is going on here.

If you want sharp edges, at the cost of a little bit of screen size, set L/T border to 8 and Display to 704.
[Jeffrey – notice how going from 704 to 706 causes an unexpected shift to the left?]

Stupid forum kicked me out and trashed message again. Obviously the ****er that wrote it never heard of mobile devices losing signal, or sessions. Wiki works, so I’m pointing my finger at the forum code…

anyways, had ShareFS on iconbar and I didn’t put it there, so I reconfigured and made a new cmos file. Now shutdown and restart are okay. Dunno if it is ShareFS or a subtle cmos change…either way, gone away.

I’ve been tweaking my MDF for best results. Still can’t get a full 720 or 576 height so more fiddling will be required… anyway…

I was going to throw in so NTSC defs so it’d be useful to people no matter what video standard they have, and I noticed the OMAPVideo module doesn’t have the commands for this.

As the s-video is now a part of the standard ROM (yay!), would it be possible to include the commands *TVMode and *TVOut (and, at your discretion, *TVRegs so I can eyeball the datasheet… (^_^) ).

Thanks.