Let's get started with a Pandora port

I’ve redone the Cortex port wiki page and added a software compatability page here – feel free to start filling it with stuff! (Although I’d hope that most of the incompatible software will vanish once we get the unaligned load/store abort handler sorted out)

OK I am being a desktop tart <—as if anyone didn’t notice from my link above…

Here is a list of programs that would be nice to have included:

- The theme manager <—Chris has already said he is happy for that to be included (although it would be sensible for it to start to include backdrops and easier configuration)

- FullNames by Andrew Booker (source is included http://www.ajb121.net/riscos/ )

- AppsClock from above too

- SmartMenu by Dick Tanis ( http://www.theochem.ru.nl/dtanis/riscos.html )

- Mousesprs – don’t know the source but it can be downloaded from http://www.themes.iconbar.com/software/

- Scaler by Nick Jarman & Roger Spooner (http://www.armclub.org.uk/32bit/ <—contact druck as he 32bit safed it?)

Of course there’s also the X-Ample stuff – confix and HiD however X-Ample seem to have given up on RISC OS ( USB here: http://www.xat.nl/en/riscos/sw/usb/index.htm and confix here: http://www.xat.nl/en/riscos/sw/confix/index.htm ) so perhaps a deal could be done?

I would also include Steve Fryatt’s PCKeys application as not all applications understande the idea of the home and end keys…

Anyway just a list – obviously configure plug in front ends would have to be written for them to get them properly intergrated.

If implemented the above list would make RISC OS 5 much nicer out of the box!

Hope this helps.

Aaargh! the tildasign is scewing up the URL for SmartMenu here – use www.theochem.ru.nl/tildasigndtanis/riscos.html

Sorry it is such a pain but I assure you it is a groovy program :-)

Keith, I agree that there are quite a few utilities which would make RISC OS behave much better out of the box – indeed I use a lot of the programs you mention. I also like Mauser and WinSnap. I get the feeling that many of these things could be migrated into the OS itself should someone take the time to do it.

While I have your attention, where did your boot sequence come from? Was it one built from our CVS using our ‘Disc’ build or was it something you threw together for the job? If it was the standard one, I’d be very interested to hear any bug reports before it gets a wider distribution.

Steve,

What would this take?

Could Chris Wraight’s Theme manager switch on and off such programs (assuming of course permission was given)?

I have been trying to work out how a configure plugin works but then realised that it will at least involve more than mucking about with obey files as I’ll need to make a little window that says yes or no to the program I want to trigger to enhance the desktop…

Speaking of which there’s that program of yours that would go a long way to enhancing things (& works on a beagleboard too…)

The !Boot folder I am using on my beagleboard is one that jeffrey emailed to me last thursday – I can’t use CVS so if that sounds current I can say what works and what doesn’t if it will help.

Jeffrey,

Apologies for not adding to the wiki – I’ve been a bit busy tonight to get all the version numbers etc. of the stuff that is working so far.

I’ll try and get something up in the next couple of days.

We have to be careful here what gets thrown into boot. Indeed, this is where packaging would help, since people could then select stuff might not be wanted in general. In particular, although the various extensions, and extra configuration are excellent choices, things that alter the behaviour of RISC OS might not be. The changes in Select are good examples, but not everything Keith has listed might be.

Not only that, but we need to obtain proper permission, under a hopefully permissive license (BSD or whatever). And we really need to ensure we can get the sources to any components. None of this is tricky, but if it’s not done, it’s going to cause problems later.

I agree with Peter here. The whole point of the Theme Manager plug-in is that it controls capability that’s already built into RISC OS (IconSprites, ToolSprites and WimpVisualFlags) – it just had no readily packaged interface. I’d be happy to look into extended its functionality a bit (i.e. wallpaper, separating window gadgets from file icons), but I don’t think it should be capable of controlling other Wimp extensions.

My general view is that !Boot is already far too cluttered with Obey scripts and applications in Resources, Choices, etc. The utilities mentioned by Keith are great and really useful, but I think their capabilities should either be added to the OS properly, or they should remain as third-party apps that a user can add or remove at will.

Just my thoughts :-)

My general view is that !Boot is already far too cluttered with Obey scripts and applications in Resources, Choices, etc. The utilities mentioned by Keith are great and really useful, but I think their capabilities should either be added to the OS properly, or they should remain as third-party apps that a user can add or remove at will.

Don’t confuse the disc image we’re working on with !Boot – that’s only a part of the disc image. I would like to see these features built into the OS where possible (mostly in the Wimp) at which point it would be logical for a Theme Manager to control them.

Other apps would be included in a disc image but probably not installed by default – to give the standard (pretty naff when you actually try it) out-of-box RISC OS experience. There would need to be a simple way for the user to activate various of these features, but it would be overkill to have the Theme Manager do it.

Anyone on here seeing this issue?

http://groups.google.com/group/beagleboard/browse_thread/thread/5b8385f0bb1f63da/

Appears that it affects C2 and C3 Beagles, the Touch Book, and pretty much anything else with an OMAP3530. They say they’ll have the issue worked around in the Beagle C4, but…

I was thinking of getting a C3, but seeing this… So, I thought I’d ask if anyone was having that problem.

Yeah, I’ve been keeping an eye on that thread for the past few months. I haven’t really used the EHCI port on my beagleboard heavily enough to know if it’s a problem that affects my board. The closest I’ve come to encountering the problem was when running one of my USB speed tests after the board had been left on for several hours – the test would fail with an error part way through, and all the connected USB devices stopped functioning. Which either meant the USB drivers died or the EHCI hardware died (or both!) – and since the bug only seemed to occur when in the WIMP I couldn’t use the debug terminal to take a closer look at the situation.

And then the day after, when I tried the same test again, everything worked fine.

Mine is a Rev C3 and I haven’t noticed anything yet. I currently run everything (keyboard, mouse, memory key (RISC OS) and Ethernet (everything else) through the EHCI port because I don’t seem to be able to find a working OTG connector (I picked up something very dodgy from Maplin that doesn’t seem to work on any of the operating systems that I have tried).

Just as a matter of interest, I have run the dd test under Angstrom 3 times with no sign of failure (using an 8G USB memory key). It might be a good board or it might just be in a good mood. I will keep an eye on this.

Glad it’s working, though you have quite an old version of the plug-in, by the looks of that theme.

BTW, Chris, I’ve been using a modified version of your toolsprites. I changed it so only the titlebar colour changes when the window is active and I changed the active colour to yellow/beige.

Screenshot: http://wii.smoothartist.com/riscos/screen.png

I can send you a copy of the modified toolsprites if you want?

I think that when the old-fashioned window & menu textures are turned off, and the old 3D window border effect is turned off, RISC OS looks a lot less dated.

So I did that and tweaked your much cleaner looking toolsprites to look more like the traditional RISC OS window furnature colour scheme. Overall, I tink it retains a very “riscosy” look, without looking so 1990s. :)

That looks great :) Please do send me a copy, and I’ll give it a spin on VRPC. If you’d like it distributed, I can host it on my webspace.

I’d really like to make a new release of the Theme Manager, as the one sitting on my computer is a bit more flexible. For example, you can choose to only override the toolsprites (+ things like radio gadgets), and leave the file icons alone. This should please people who like (for example) the Steel window furniture but prefer the RO5 directory/file icons.

The remaining issues are two:

- I’d really like to enable Select-style button colouring for the next release, since without it theming remains incomplete. I know Fred Graute had made some good progress on this, but I’m not sure where it is at the moment.

- There’s an issue with a rogue WimpVisualFlags command appearing after the Theme Manager’s own copy on RO5, which is a bit messy (users have to delete it manually atm). I’ve not been able to really sort this out, as I use RO4 on VRPC, but now that the !Boot sequence has been released, I might see if I can fix that.

As ever, help with this is much appreciated. I can handle the theme creating bit, but I don’t have assembler, so can’t do much with the relevant bits of the Wimp :(

On the topic of EHCI problems I have tested 2 C3 boards and one out of 2 seems to have a problem related to the USB Host. Apparently this is a power problem on the 1.8V I/O lines and a possible fix is to add an extra capacitor to the 1.8V I/O supply. I.i.r.c. this is adding a cap of 22uF across C97. This has shown to fix a lot of boards, but again, not all of them. Fortunately it fixed the BB over here.

Hope this helps others too.

Chris: I’ve just e-mailed you a copy of the toolsprites. You’re welcome to host it. :)

BTW, Chris, I’ve been using a modified version of your bq. toolsprites. I changed it so only the titlebar colour bq. changes when the window is |active and I changed the bq. active colour to yellow/beige. bq. <snip> bq. So I did that and tweaked your much cleaner looking bq. toolsprites to look more like the traditional RISC OS bq. window furnature colour scheme. Overall, I tink it retains bq. a very “riscosy” look, without looking so 1990s.

Very nice, I look forward to using it.

I’ve just checked in some fixes to a few nasty bugs I found in the MUSBDriver. Luckily it looks like most of the lockups were caused by a couple of silly bugs in my code – control transfers weren’t getting queued properly, and bulk/interrupt endpoints were being reassigned to other transfers while they were still in use by their original owner. Now that these bugs are fixed USB seems a lot more stable and reliable – I’ve been able to use hubs, multiple mass storage devices, etc. all without any problems. I’ve also fixed the packet receive code so it correctly handles short packets, which means that USB-LAN adaptors also work properly.

It goes without saying that owners of rev B boards will want to get the latest code ASAP so they can take advantage of these fixes (and to let me know if they encounter any other problems!)

I think it is now the right time to add a hardware compatibility page too, at least for the Beagle Board. I’ll add it.

Looking at the latest advances in the USB mass storage speed improvements it seems that the BeagleBoard may become a nice platform that can build its own ROM. I have tested if it would work but it appears that ‘squash’ is missing. Adding it to the ROM unfortunately does not really help. The squash module is supplied in binary and possibly has some ‘old’ or known OMAP issues. Hopefully that will get resolved soon and we can start using BeagleBoards for compiling ROMs.

Thanks Jeffrey and all others who have worked on the port to the OMAP!

Good point. While we’re stuck with a pre-built binary release of Squash, we need to remember to update this to be ARM v7 safe. I’ll try to remember to do this on Wed.

Hi all.

I just thought I’d chime in to say that I’m currently updating the extASM assembler to the latest ARM versions, and it might also be used as a replacement assembler for BBC BASIC’s assembler, should that be a practical possibility.

Currently, most of the ARMv7 instructions are implemented (including the Avanced SIMD and VFP instructions), so now, a probably extended period of testing will follow, to test all the instructions and their variations.

I’ve bought the BeagleBoard [1], but I haven’t yet run RISC OS on it, using Virtual Acorn for the development at present. Naturally, to test programs using features in these later ARM versions will require actual ARM hardware.

When complete, extASM will be released as open source.

Regards,

Terje

[1] I’ve even ordered a Touch Book (yes, I’m an optimist :) ).

Edit: Thanks for the corrected link, Alan. I’ve now corrected it in this posting.

problem with use of tilde sign in above link. Actual link below.

extASM

Just to keep everyone up to date, I’m now starting work on the sound driver, and DMA support. As suggested by Ben a few pages back I’m going to try retooling SoundDMA to use the DMAManager module to manage the DMA transfers. And sound itself is a good test to see if DMAManager & the HAL DMA code are working properly, so the two tasks of getting sound working and of getting DMAManager working complement each other nicely.

To start with I’ll just be doing a basic DMA implementation to fulfill the needs of DMAManager, but in the future (mainly for graphics acceleration) we’ll probably have to think about how best to expand the API to allow the use of DMA fill, rectangle copy/rotate, etc.

Star Fighter 3000 has been updated to run on the BeagleBoard, and Jeffrey’s screenshots show it running about twice as fast on a BeagleBoard than on an Iyonix, which is quite good.

http://www.iconbar.com/articles/Star_Fighter_3000_updated/index1238.html

Will the DMA graphics accleration improve that kind of thing further?