S-video build for Beagle?
Pages: 1 2
Rick Murray (539) 13806 posts |
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): |
Jeffrey Lee (213) 6048 posts |
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. |
joe (1350) 19 posts |
@ Master Rick, @ Master Jeffry Lee, |
Jeffrey Lee (213) 6048 posts |
Joe – The image I uploaded should work fine on both the BB and BB-xM. |
Rick Murray (539) 13806 posts |
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. |
Rick Murray (539) 13806 posts |
Jeffrey – thank you. I’ll try it later today (got to go out now). |
joe (1350) 19 posts |
Thanks guys. |
Trevor Johnson (329) 1645 posts |
I guess that’s the forum ID or something. |
Steve Revill (20) 1361 posts |
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! |
Rick Murray (539) 13806 posts |
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. |
Trevor Johnson (329) 1645 posts |
You’re going to be busy catching up, but please don’t stop! |
Rick Murray (539) 13806 posts |
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. |
joe (1350) 19 posts |
Where did you find this 3500 pages manual, I found this one DDI0344H_cortex_a8_r3p0_trm.pdf from here: |
Trevor Johnson (329) 1645 posts |
The ROOL wiki includes some links to docs. If you find a broken link and relocate the actual doc, please update for others! |
Rick Murray (539) 13806 posts |
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. 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. |
Rick Murray (539) 13806 posts |
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:
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). Best wishes, Rick. |
Rick Murray (539) 13806 posts |
Jeffrey – where in the plethora of code that is RISC OS would I find the parts for driving the TV output? |
Rick Murray (539) 13806 posts |
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”. 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. |
Colin Ferris (399) 1809 posts |
Which version of the ‘C’ compiler are you using? -memaccess – L22 -S22 |
Colin Ferris (399) 1809 posts |
There is an advert for a s-video to VGA cable – any ideas if that would work with the Beagleboard? |
Jess Hampshire (158) 865 posts |
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.) |
Andrew Rawnsley (492) 1443 posts |
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. |
Jess Hampshire (158) 865 posts |
here’s an improper alternative: |
Jeffrey Lee (213) 6048 posts |
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:
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… |
Rick Murray (539) 13806 posts |
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!). 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. |
Pages: 1 2