It’s the BeagleBoard-xM reference manual that we need, not the AM/DM TRMs. Only the -xM manual can confirm what chip is used on the board (I/we already know that the DMxxx contain a DSP while the AMxxx don’t)

The SGX was the graphics accelerator wasn’t it? Is a DSP a different GPU with better documentation?

No, the DSP is a DSP :) It’s a CPU that’s optimised for audio/video encoding/decoding. I haven’t really looked at the documentation much, but I believe everything that we need is available (instruction set details, a free compiler, etc.)

Also is the XM a worthwhile investment when no doubt in a year or two, another beagleboard (XM+ maybe?) will no doubt appear putting the older hardware to shame?

The next beagleboard is likely to be the pandaboard, which will be a multi-core OMAP4. It will undoubtedly put the -xM to shame, but there’s no telling how long it would be until RISC OS would be able to take full advantage of it.

On another topic, do those DVI>VGA adaptors that come free with most PC graphics cards work with the beagle board to allow output to a VGA monitor?

Unfortunately not. Most/all PC graphics cards output both digital and analogue signals, the DVI>VGA adaptor that comes with the card will simply route the analogue signal from the PC to the VGA socket. The DVI socket on the beagleboard is digital-only, so an ordinary DVI>VGA adaptor won’t work. (Plus there’s also the fact that the beagleboard only uses an HDMI socket instead of a full DVI one, and as far as I know HDMI doesn’t support sending an analogue signal alongside a digital one anyway)

I have ordered a Beagleboard XM and will let you know when it arrives so that I can help with debugging the RISC OS port. I’d be interested in getting a Touchbook but only once I know that RISC OS is working on it. I have deliberately not gone for the non-XM Beagleboard as I will now not consider any RISC OS computer without on-board Ethernet. This paid dividends in the case of the Omega confining my loss to the deposit and not the cost of the whole machine. I even paid the deposit by credit card in the mistaken belief that I would be able to get my money back from the Armtwister sharks that way (it’s apparently limited to 90 days).

I’d just like to point out that the ordinary BeagleBoard works very well with Ethernet, with at least three different USB Ethernet dongles and EtherUSB. Everyone is entitled to his or her opinion, I merely want to ensure that no-one is given the impression that there is any difficulty with BeagleBoard Ethernet.

Plus, they have plenty of serial cables! (The -xM has a female DB9 connector designed to connect directly to USB-serial adapters – which means that if you’re connecting the board to a machine with a real serial port you’ll need a straight male-female cable instead of the more typical female-female null-modem cable)

For the people that are worried about needing serial cables – it should only be developers that need to buy them. The xM doesn’t have any NAND, so as long as you set up the SD card correctly there’s no reason why RISC OS won’t boot when you plug the card in (unless I’ve managed to break the ROM :P).

It may also make sense for us to start distributing the ROM as a SD card image, the same way as the xM verification image will be distributed. This will remove any problems caused by operating systems formatting the SD card incorrectly, or people forgetting to copy a critical file, etc. And for people too unfamiliar with Windows/Linux to be able to run a partitioning tool to write the image to the disc it shouldn’t be too hard to write a simple BASIC app that uses the SCSI sector op SWIs to write the image to the card (Although that’s obviously only of any use if the user has an Iyonix nearby!)

The reference manual also confirms that the board is using the DM3730, i.e. it has the DSP. However they’re using 166MHz memory because of the problems with the 200MHz Micron parts :(

Helpfully, so far Farnell don’t seem to stock the battery for the RTC :-(

It doesn’t look like they’ve got anything similar either – all of their PCB-mountable batteries seem to be either 3-pin ones or widely-spaced 2-pin ones.

This is crazy – Mouser list the battery (along with a load of other batteries from the same manufacturer) as being a restricted item! What on earth is so dangerous about allowing people to buy 3V button cells?

OK, for some reason this didn’t show up in my search, but Farnell do sell the MS621FE-FL11E, which is a larger capacity version of the one mentioned in the reference manual (5.5mAh vs. 1mAh). Looking at the data sheet it looks like it’s a suitable replacement.

I’ve also found the relevant bits in the TPS65950 manual about how to control the backup battery charging, so once I’ve got my board I’ll have to write some code to enable the charging circuit (I suspect u-boot/x-loader won’t turn it on themselves)

This is crazy – Mouser list the battery (along with a load of other batteries from the same manufacturer) as being a restricted item! What on earth is so dangerous about allowing people to buy 3V button cells?

I think they list most batteries as restricted items because there are shipping restrictions on sending batteries through the post, especially by airmail! There must be someone prepared to import the things though. Maybe it will need someone to nag Farnell into stocking it. Hopefully Micron will get their act together and sort out the memory problems so the 200MHz can be fitted to the next batch.

OK, for some reason this didn’t show up in my search, but Farnell do sell the MS621FE-FL11E, which is a larger capacity version of the one mentioned in the reference manual (5.5mAh vs. 1mAh). Looking at the data sheet it looks like it’s a suitable replacement.

Ah, thanks, I missed that one too! It’s a bit bigger, but that shouldn’t pose a problem, I wouldn’t think.

I’ve also found the relevant bits in the TPS65950 manual about how to control the backup battery charging, so once I’ve got my board I’ll have to write some code to enable the charging circuit (I suspect u-boot/x-loader won’t turn it on themselves)

Just a word of warning that Farnell/UPS have a funny definition of weekend delivery. I’m assuming that they just messed up because the order’s been split in two, and that they’ll use the correct delivery option for the beagleboard.

Either way, I now have a few extra days to practice with the soldering iron before I get to try fitting the ridiculously tiny battery to the beagleboard.

I had an order of about 50 packs of resistors from Farnell, some of which were out of stock. They’ve been sending them to me in dribs and drabs since April, sometimes by post, but they’ve twice send one pack of 50 resistors (cost approx 40p) by Courier! Given the number of shipments they’ve made, they must have made a significant loss on my order!

If Gerald’s reports of DigiKey only having a backlog of 350 preorders are true then I suspect it won’t take more than a couple of weeks for everyone to receive their boards. To ship 8000 by the end of the year they’ll have to build around 500 a week.

No shipping notification for me yet (not that I was expecting one until at least the end of the week), but I’ll do a quick check through the xM reference manual to make sure RISC OS will boot OK when you get your board. I’ve also got a rough tool that you’ll be able to use to ensure the SD card is formatted correctly – I used Linux to make a blank 8MB FAT disc image that’s in the right format for the OMAP boot ROM. DOSFS can then be used as an image filing system to copy x-loader, u-boot and a ROM image into the disc image, and a few lines of BASIC can be used to write the finished image to an SD card using SCSIFS_DiscOp. So if we supply OMAP ROMs as finished SD card images (or a tool to create the images) then that will remove a lot of the hassle that users have to go through to set up their cards (and reduce the risk of them making mistakes).