S-video build for Beagle?

Hello,

I have managed to get RISC OS 5.18 booting on my Beagle xM. Using the keyboard, I can hear a beep for ^G, however typing the TVOut/TVMode commands do not seem to have any effect.

I am typing blind because I have no HDMI capable monitor (nothing HD). Therefore, are these commands present in the v5.19 version, or do I need a debug build of RISC OS?

If the latter case, surely I can’t be the only person that would want to use RISC OS via s-video? If there is somebody else, could you please link a ROM image that supports this?

Thanks.

Best wishes,

Rick.

PS: Didn’t use SDCreate (no RISC OS machine with SD card), however for the xM, it all seems a bit complicated. I just dropped the image on to the test microSD card and created “user.txt” containing (and I’m not sure the first two lines are necessary):
-8<———-
mpurate=1000
buddy=unknown
defaultdisplay=tv
uenvcmd=mmcinit;fatload mmc 0:1 0×81000000 riscos;go 0×81000000
-8<———-
Now RISC OS will boot (albeit with a blank display) when I start up with the user button held down. I’d sort out CMOS and filesystem later – when I can see stuff! (^_^)

I’ve uploaded a ROM here which has the TV output enabled. It’s set to use the TV output by default, with a PAL video signal.

Up until now people haven’t shown much interest in using the TV-out, so I haven’t made any real effort to get it fully working. I’ve given that ROM image a couple of tweaks to make the TV-out more usable, but it’s still rather buggy, so don’t expect too much from it. If you’re lucky I’ll find some time over the weekend to look into the more serious issues.

@ Master Rick,
you haven’t explained how you simply dropped the RISC OS image onto the micro SD, what operating system,
which partition and where did you put the “user.txt” file, when I modified the original card it was no longer accessible, luckily I cloned mine before any attempts to play with it.

@ Master Jeffry Lee,
is there any beagle xM image also available for download?

Joe – The image I uploaded should work fine on both the BB and BB-xM.

joe – as mentioned in more detail on my blog, for the xM (not the original), place “riscos” into the FAT partition (you’ll find a lot of non-Unix stuff simply won’t see the other partition!), then place the “user.txt” file alongside it. User.txt should be LF line endings, not CRLF like in Windows.

Be sure to properly and fully dismount/eject the microSD. Then it should work. What system did you use to do this? I used XP (eeePC).

Best wishes,

Rick.

Jeffrey – thank you. I’ll try it later today (got to go out now).

Thanks guys.
I will use Ubuntu to create the text file and copy the file in sudo mode,
Linux console is much more powerful than DOS one.
At some stage I was confused, I’ve thought I posted 1350 times.

At some stage I was confused, I’ve thought I posted 1350 times.

I guess that’s the forum ID or something.

I guess that’s the forum ID or something.

Yes, that’s your user number. I’ve no idea why it’s displayed in the forums; I can’t see how it’s relevant. But it’s great to see we have well over 1,000 users of the ROOL site!

Just to follow up… BIG SMILE!

Still got a lot to do (no CMOS file, no boot disc), but I now get the supervisor prompt and *desktop goes into the desktop. It also seems mind-numbingly nippy.

The display doesn’t fill the screen – is this a limitation of the current driver, or just a side effect of not having a suitable MDF? I’ve not read the TRM yet (yikes, three and a half thousand pages!), however if it is anything like the DM320, isn’t the basic video stuff just a framebuffer? Still, it is never that simple – my PVR reloads the entire UI when switching between PAL and NTSC even though the framebuffer is 640×480. I guess maybe the scaling relationship is different or something?

Either way, I’m really happy to be getting RISC OS going on the xM.

Thank you again.

Best wishes,

Rick.

yikes, three and a half thousand pages!

You’re going to be busy catching up, but please don’t stop!

I’ve played some more – got the OS and boot stuff installed. I’ve also run MakeModes and put together a little MDF for the Beagle’s s-video to offer a standard 640×480 and a larger 704×552. I’ve not really paid much attention to the other settings (front porch, etc), I just hit “Try” loads of times to see what worked. It’ll need some tweaking, but it is a start. Any further work, I’ll need to poke around the video driver source and the datasheet to ensure I’m not getting the OS to write bogus values to the OMAP’s video. As it is, things get a bit freaky over 704px width, yet I think Angstrom does a larger display, so I’ll need to get in touch with Jeffrey (and cast my eye over that bloody HUGE TRM) to see what/how the video system works.

Details, pictures, MDF download, blah blah at: http://www.heyrick.co.uk/blog/index.php?diary=20120518

Ah well… I’m off to watch Sankarea. Later… ;-)

Best wishes,

Rick.

Where did you find this 3500 pages manual, I found this one DDI0344H_cortex_a8_r3p0_trm.pdf from here:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344h/index.html
it’s only 758 pages.
Hey Rick you are the champion, thanks.
Is your web page ready for like thousand visitors a minute?

The ROOL wiki includes some links to docs. If you find a broken link and relocate the actual doc, please update for others!

Joe – a thousand visitors a minute? That’s possibly more visitors than Beagle RISC OS users! Mmm, must be my good friend Yandex.ru. ;-)

While I’m not overly keen on the subtle suggestions of possibly dropping work on the Beagle now the faster Pandora and cheaper RPi are available (smacks too much of Ubuntu’s “ewww, it’s a mere ARM11” attitude); one thing nobody can deny is our best shot is, indeed, the RPi. The likes of the Beagle are perfectly capable machines for RISC OS (and a lot being written in good tight ARM code, the entire system flies) but their price means that they may not be entirely suited for people wishing to have a nostalgia trip, or for inexperienced people to play with the GPIO. The RPi puts fun & frolics in the reach of everybody with geeky inclinations – so logically RISC OS stands to make its biggest impact there.
Hopefully the HAL/OS separation means all supported systems can continue to evolve in sync.
Now I have the hardware, I plan on saving up for the latest DDE. Then the next hurdle will be how much time I have free (and as a night shift worker, to say my concentration has nosedived into oblivion would be rather an understatement). But, gotta start somewhere, eh?

For the document, I just Googled the chip number (3730 if I remember correctly) followed by TRM and looked down the list until I found TIs site. There are two documents. One (around 4MiB) describes the pinout, electrical signals, etc. It is really boring! The other (around 26MiB or so) describes the chip’s operation. This is the one you want, but be warned it is a dry technical document of epic proportion, not the sort of thing you’ll read for fun (it makes the RISC OS PRMs look like light novels in comparison).

Speaking of nostalgia, this time exactly ten years ago my mother and I were in Portsmouth ferry terminal awaiting our final trip to France. It would be my last day in England.

Best wishes,

Rick.

Just an update – the blog page http://www.heyrick.co.uk/blog/index.php?diary=20120518 has been updated to reflect that the BeagleMDF now supports:

• 640×480
• 720×576
  [the earlier 704×552 has been removed]

Screenshot on the blog page – the display now fills the screen (would be best with monitors/tv capture devices, as a regular TV might clip the edges).
There are still a few pixels off the bottom of the display, maybe 6-8?, these I cannot recover as the top margin/sync is already as small as it can be – I’ll need to get in touch with Jeffrey and read that huge PDF!

Best wishes,

Rick.

Jeffrey – where in the plethora of code that is RISC OS would I find the parts for driving the TV output?
The file HAL/OMAP3/s/video says “Currently this code only supports the RFBI bypass mode”.

random follow up:

It seems my (older Castle) compiler won’t work unless I switch off alignment exceptions. This, interestingly, makes !PDF work too instead of reporting “Task not known”.
One of my programs behaved the same way with my custom hack of DeskLib 2.30. I tried v2.80 but that crashed at startup either way. I’ve reverted to mine, I’ll dig up the source and rebuild it (was last built circa 2001 on my RiscPC), see if that improves stuff.
It was for a forthcoming program to configure MoreKeys. Interestingly, MoreKeys itself works fine as I did not use any libraries, but wrote the API interfacing from scratch in assembler; but I used DeskLib for the other as it has a lot of GUI stuff and I couldn’t be bothered to do all of that from scratch. ;-)

As a side note, I’ve cobbled together some code to turn the two user LEDs on or off. I think I’ll make a module to turn them off, and then 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 upon FileV (so it’ll look a little like a disc lamp). More when I have something to release…

Best wishes,

Rick.

Which version of the ‘C’ compiler are you using?
Remember for compiled code – to use the flags below – to produce code that will work with rpc – beagle.

-memaccess – L22 -S22

There is an advert for a s-video to VGA cable – any ideas if that would work with the Beagleboard?

You’d probably be better using an HDMI – VGA converter.

S-video is the wrong frame rate, and would require converting.

This usually looks horrible with a computer type display. (Not so bad on a movie)

(The beagle could probably put out the correct frame rates, but you would need a simpler circuit, which you may not find off the shelf.)

Proper HDMI→VGA convertors are also fairly expensive (eg. HD Fury – 70-80ukp). The inline adapters assume the graphics card output includes a VGA signal and merely provides the necessary analogue pin-out for hookup.

here’s an improper alternative:

http://www.linusakesson.net/hardware/beagleboard/vga.php

The file HAL/OMAP3/s/video says “Currently this code only supports the RFBI bypass mode”.

That file’s a bit of a red herring, since most of it isn’t used anymore. What you really want to be looking at is the OMAPVideo module (bsd/RiscOS/Sources/Video/HWSupport/OMAPVideo). And in the OMAP TRM, you’ll want to look for the documentation for the video encoder (VENC) and the registers for the digital output in the display controller (DISPC). DISPC has two main outputs – the LCD output is used for the DVI/HDMI output on the beagle (and the LCD connector), while the digital output is (I believe) hardwired within the OMAP to only supply a signal to the video encoder (despite the fact that composite & S-Video are clearly analogue signals!). Things are a bit more sensible on OMAP4 where I believe the “digital” output goes to the HDMI controller.

I believe the video encoder is fully programmable for most/any display timings, but the documentation is surprisingly light on details for how to program your own display modes. So at the moment the OMAPVideo module just sticks to the standard NTSC or PAL modes (using the register values listed in the programming guide in the TRM), and crops/centers RISC OS’s display to fit the screen (although I haven’t checked in the code for this yet). The centering code takes into account the porch/border values from the mode timings that you/RISC OS supplies, so to fix some pixels being off the bottom of the screen you can either decrease the porch/border timings for the top edge of the screen or increase the timings for the bottom edge. Or you can even use the old *TV command (which causes the kernel to adjust the vertical porch values in units of +/- 8 rows)

Known issues with the TV-out include:

• Corrupt image when the mode is larger than the screen. I’m not entirely sure what’s causing this, since I’m fairly certain the code that crops the graphics overlay to the screen is correct.
• Wrong colours (everything blueish) in 16bpp modes. This is down to the gamma table being filled incorrectly (I think I need to implement an alternate version of the gamma table fudge that’s used to get 16bpp modes displaying correctly on the DVI output). Plus I think there’s a bug in my original code anyway, since it doesn’t seem to set up the gamma table so that the OMAP ignores the top bit of the blue channel.
• Red/blue swapped in 24bpp modes (and 16bpp modes, although the dodgy gamma table is the more obvious issue). There’s no easy fix for this since the OMAP native colour format is &RRGGBB instead of RISC OS’s &BBGGRR. For the DVI output this is handled via the colour phase rotation matrix, but that matrix isn’t available for the TV output, so we’ll have to teach RISC OS about some new pixel formats and/or implement a software layer to trap screen reads/writes and translate the colour format there.
• I’ve been running into some odd issues on my BB trying to get some MDF entries to work (e.g. 640×480). Something seems to be telling the OS that the mode can’t be used, but I’m not sure what, since the code in OMAPVideo that vets the mode timings is mostly disabled if TV-out is in use (since it ignores most of the timings anyway).
• It might be related to the corruption issues with modes which are larger than the screen, but sometimes the mouse offset is incorrect.

Also when making your modes in MakeModes, you can pretty much ignore all the warnings it gives you about invalid mode timings. MakeModes only understands VIDC timing constraints, most of which won’t apply to newer hardware. Another thing to fix that’s still lurking on the todo list…

Colin – C compiler 5.51, it doesn’t like the “-memaccess” command. The problem is running the compiler itself… I guess I’ll need to save up my pennies for the latest one. I hope ROOL can do me a USB key with the compiler and sources so I can just plug it in, type “make” and get a ROM image at the end.

Jess – awesome hack. I like that! (^_^)

Jeffrey – thanks for the pointer. I didn’t think to look in “bsd”. I would imagine the screen area is X by Y – the DM320 was specified as 640×480, there doesn’t seem to be a definite setting for the OMAP3 however the largest valid size of a PAL frame is 720×576 so I’d imagine that would be what we need to constrain to? I noticed, also, the quirk with some 640×480 modes being rejected. Fiddling with the border/sync can sometimes coax MakeModes into working, however I’ve yet to get a valid 320×240 mode (just for fun, it’d surely look like a postage stamp!).
Given that we have 512MiB onboard and there’s no obvious issue between 256 colours and 16M colours (other than R/B swap), I wonder if we even need a 32K colour mode these days?
I think the quickest hack for today would be to find a way to intercept the screen writes and just swap the values over. Not sure, in practice, how much that would impact system performance. However, as I said, it’s a hack until RISC OS instinctively understands different pixel formats…

There’s another oddity. If the sync/border values are wrong, or the mode is too big (but not enough to freak it out entirely), the display either goes washed out or dark. I’m not certain if this is an effect of my USB capture device dealing with a bogus signal, or if it’s the OMAP video encoder.