5.18 stable release wishlist

It looks like it’s possible to squeeze everything in. But it looks like there are a couple of bugs that need to be tracked down (Including SharedSound stops the machine from booting at all, and with SharedSound removed I get an “Overlapping areas” error when entering the desktop). So I’ll have to work out what’s causing those problems before I can check anything in.

Is there a possibility of including J.G Harston’s
updates to BBC BASIC & perhaps the Module Basalt?
A *Where command would be handy.

SharedSound is now in the Iyonix ROM image (and the other ROMs), but the other modules (the SCSI ones) aren’t. It looks like Aemulor doesn’t like it if I reduce the Iyonix HAL size from 64K to 32K, as that’s where the “Overlapping areas” error was coming from. That 32K of extra space was needed to allow me to fit the SCSI modules in, so rather than break Aemulor for everyone it looks like we’ll have to stick with softloading the modules, or I’ll have to try and find somewhere else to squeeze some space from.

Is there a possibility of including J.G Harston’s updates to BBC BASIC & perhaps the Module Basalt?

Possibly. I think it will depend on how long it takes to get everything else done.

A *Where command would be handy.

There’s the DebugTools module on the modules page, which has a *Where command. I’m not sure whether including the full module would make sense, but we should probably at least add the *Where command to the Debugger module.

or I’ll have to try and find somewhere else to squeeze some space from.

Could paint be removed and made into a normal app?

Presumably the SCSI modules provide the facility to !boot from a USB drive, and this is desirable.

Could paint be removed and made into a normal app?

Hasn’t it been moved out of and back into ROM before? Is Paint useful to keep in the ROM because of its snapshot facility – is it potentially useful for debugging?

I don’t think it would make sense to remove Paint at this point in time – running out of ROM space is just a temporary issue until we can add compressed ROM support. All we’d do is cause people hassle by forcing them to install it to their hard disc, and then make them delete it again if it gets re-added to ROM in future.

Last time we were running low on ROM space I made a list of files in ResourceFS that could potentially be squeezed. Chances are I’ll be able to find the space I need there.

The SCSI modules are now in – I was able to save about 40-50K by squashing the lookup tables that ColourTrans uses. This means ColourTrans will take 64K of memory from the RMA, but (on an Iyonix at least) that’s balanced by the fact that the SCSI modules no longer need to be softloaded. It’s trivial to change back to the uncompressed files once we have compressed ROM image support.

I’ve also tweaked the order in which CDFS searches for drives, which should prevent SCSI CD drives hiding ATAPI/CDFaker ones and vice-versa.

Is their (or will there be) a release candidate that we can softload and test?

Do USB CD drives now hot plug or do they need to be there on boot?

Would a numbered mode for 1024 × 768 256C 60Hz be possible?

It would also be nice to have modes corresponding to 720 and 1080 TV

Just answering the first point, I’m happy to QA stuff (I believe I said so previously, but I’ll re-affirm it now). Indeed, I have begun testing this week. I’ve been having problems emailing Jeffrey directly because the phlamethrower domain isn’t resolving, and with me being unavailable a lot recently, I’m a little behind, but just wanted to say thanks for the CD stuff, which seems to be working brilliantly.

Do USB CD drives now hot plug or do they need to be there on boot?

There isn’t full hot plug support, but it looks like the drive will be detected OK if you connect it after boot. You just need to make sure you’ve got the number of CD ROM drives configured correctly.

I’ve been having problems emailing Jeffrey directly because the phlamethrower domain isn’t resolving

I’m not sure what’s going on there, it sounds like it’s an intermittent fault somewhere as most of my other mail is getting through fine. If it’s still giving you trouble you can always use my gmail address – phlamethrower at gmail dot com.

Suggestion regarding stable 5.18 release…

Since there’s still a slight question mark over the cmos stuff, might I suggest (with no disrespect intended whatsoever to those involved) that we back out the HAL-CMOS changes for the 5.18 release (but include the CDFS stuff since that seems OK, with no real potential problem-side-effects), then re-introduce it for 5.19? That way, we can see about a 5.18 release ASAP (before the end of the year?) and study the SD-card-corruption problems further in 5.19?

I’d also be cautious about further BASIC changes for 5.18. I suggest we go with (more or less) where we’re at, then roll in the basic changes for 5.19 as test stuff, for final release in 5.20. This would follow the Castle philosophy of even-numbered stable releases, and odd number test builds.

Since there’s still a slight question mark over the cmos stuff, might I suggest (with no disrespect intended whatsoever to those involved) that we back out the HAL-CMOS changes for the 5.18 release (but include the CDFS stuff since that seems OK, with no real potential problem-side-effects), then re-introduce it for 5.19? That way, we can see about a 5.18 release ASAP (before the end of the year?) and study the SD-card-corruption problems further in 5.19?

I think the SD card corruption bugs are all fixed now. But since it’s practically impossible to test every possible card configuration I guess it would make sense to disable the CMOS save code for 5.18. If people want the code then it’s easy enough for them to switch to a near-identical 5.19 ROM shortly after 5.18 is out.

Latest changes:

• NetTime is now in the disc image. However I don’t have enough time to create a configuration GUI for it, so it’s just being supplied as a module in System:Modules.Network.
• I’ve also tweaked the sound setup plugin a bit so that it will run the old VIDC plugin if SoundControl isn’t present. So people using the IOMD ROM should now have a working sound setup plugin.
• I’ve merged in TBA’s VFP/NEON BASIC assembler. Since there’s only one place the code hooks into the BASIC sources (when assembling instructions starting with ‘V’) this seemed like a safe change to make, even if there might still be a couple of bugs left in the assembler itself. Unfortunately lack of space in the Iyonix ROM means I’ve had to disable it there, so Iyonix users who want to use it will have to rely on softloading a new BASIC as part of their boot sequence. I don’t think this will be a major issue though, since there’s little point in someone assembling VFP/NEON code if they’ve got no way of testing that it runs.

I’m about to head off for a couple of weeks, so if 5.18 happens without me, then all you need to do to disable the CMOS save code is to comment out the call to NVMem_C_write in HAL.OMAP3.s.NVMemory.

Cheers Jeffrey, hope you have a good break.
Merry Christmas!

All the best for a great Christmas and New Year, Jeffrey!

All the best, Jeffrey!

Yes, have a great Christmas, Jeffrey, and a well-deserved break. I suspect your Christmas card may not get there in time :(

Is there a softload of a release candidate? (I notice that the dev version is now 5.19)

I would like to try it. I’m currently using 26-oct-11. I tried some later versions, but had issues with the machine locking solid with Netfetch/Hermes (It still happens once in a while, but nothing like as much.)

There are no published 5.18 release candidates; 5.18 is only released on the ROOL site when it has been deemed to be “stable”. We do this by handing our own (internal) release candidates over to relevant parties – e.g. Castle for the Iyonix build and RComp for the BeagleBoard build. Don’t forget, 5.18 is pretty much just a snapshot of 5.17 at the point where we transitioned to 5.19 so it’s already been pretty well exercised by everyone who’s running the development builds.

What we really want to avoid is having multiple versions of 5.18 floating about; this would be exactly not what developers want when developing and supporting their software.

I notice some discussion about modernizing the design.
Does anyone recall the design I made some time ago?

Also available at 800px and Picasa.

I got quite some positive feedback on this. And would be more than willing to continue working on it.

It’s nice but it looks far more like yet another Linux distro than it does RISC OS. Earlier in this thread, there’s discussion of Steel, a very nice theme (and Michael’s variation on it, to make it even more like Acorn’s NewLook). It really is a nice, modern, clean version of what we have right now.

I don’t like all those half-open folders: it’s nice to have feedback from teh filer as to which directories have a window open on screen, and which do not. The window furniture is quite nice though.

Since RISC OS 5.18 is now at release candidate 2, (rc0 and rc1 having had small tweaks) isn’t a wish list for what should be in it a bit too late?