S-video build for Beagle?
Pages: 1 2
Rick Murray (539) 13840 posts |
Quoting myself:
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… ;-) |
Rick Murray (539) 13840 posts |
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. |
Jeffrey Lee (213) 6048 posts |
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. |
Rick Murray (539) 13840 posts |
Ah, so currently no use downloading the builds on the site for those with less fancy setups. [can textile do quotes-in-quotes?]
Oh, right – I thought I noticed this happening, but didn’t play enough to note it as a definite bug.
Do you mean the display itself screwing up, or the inverted colours?
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).
What, it can tell if something is plugged into s-video?!?
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.
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: 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. |
Jeffrey Lee (213) 6048 posts |
When I need to do this I usually just cheat and use HTML blockquote tags! and corrupt display when using big modes 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:
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! No, it’s by design. Monitor type 7 was created as the “use an MDF” monitor type.
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). |
Rick Murray (539) 13840 posts |
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?
Strange that it is output-specific rather than “the video controller does this”.
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 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. |
Jeffrey Lee (213) 6048 posts |
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 :(
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.
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.
Yes you can. Code breakpoints, data breakpoints, breakpoints on processor vectors, etc. |
Rick Murray (539) 13840 posts |
Quick request – Jeffrey – could you (if you have time) make up a build of the latest version that works on s-video? Thanks! |
Jeffrey Lee (213) 6048 posts |
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. |
Rick Murray (539) 13840 posts |
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 |
Jess Hampshire (158) 865 posts |
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) |
Rick Murray (539) 13840 posts |
Follow-up… got myself the official test build of today, installed, it seems to work.
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). |
Rick Murray (539) 13840 posts |
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: 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. |
Rick Murray (539) 13840 posts |
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. |
Rick Murray (539) 13840 posts |
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 Thanks. |
Pages: 1 2