Recent Posts

Topic: Code review / Compressed ROM images

I think I’ll have a go at completely rewriting the RAM detection code that’s in the IOMD HAL. The basic code (to determine the size/arrangement of RAM in a DRAM bank) is pretty simple and will stay the same, but everything else around it to deal with splitting banks into contiguous chunks will be rewritten. This is the easiest way I can think of updating the code to fully deal with compressed ROMs, and to get rid of the issues people have been having with softloads not working. Plus it should be pretty easy to write a BASIC testbed that runs through all the different RAM combinations and makes sure the code won’t fall over.

Topic: Code review / NetTime and daylight savings

FWIW country-code server lookups shouldn’t really be necessary. One of the pool.ntp.org addresses is actually an anycast cloud, so you get the closest server to you in network terms irrespective of where it happens to be. This cloud is currently a bit sparsely populated (2 in California, one in Luxembourg) but it hopefully shouldn’t be too long before it has decent coverage. Just so you’re aware that the country code method might be obsoleted soon :)

Topic: Code review / Compressed ROM images

My experience with RO5 on a RPC is that everything breaks. My disc is full of crufty non-32-bit software, and my boot sequence the same, so I get errors all over the place (eg when application !Boot files try running things that aren’t 32 bit). Having a known-good image that I can easily drop in over RO3/4 is handy. Then I don’t need to mess about with moving !Boot out the way, trying to merge ROOL’s stuff into ROL’s !Boot, etc etc.

Topic: General / RISC OS on the Raspberry Pi

If I manage to get my hands on a Pi I’d be happy to do some testing once there’s something available. Used to use RISC OS a lot and would very much like to see it back in wider use again.

Topic: General / RISC OS on the Raspberry Pi

The port is progressing, albeit far slower than I would have liked. I hope to release it to ROOL and Theo soon, so that they may contribute.

Slow progress is better than no progress. If I’m able to get one of the boards from the first batch then I’ll hopefully be able to help out in one or two areas.

Topic: General / RISC OS on the Raspberry Pi

PrivateEye

It’s freeware. I have no objections to you including it.

(Ideally I need to get a proper ARMv7-compliant rebuild out at some point).

"Rebuilt from the open source codebase for ARMv7 compatibility. PrivateEye is now licensed under a BSD license."

(Edit: I now see this was on c.s.a.announce too.)

Topic: Code review / Compressed ROM images

One !Boot does Pretty much the same as another! With what I have added to the ROOL !Boot, if I don’t select the softload then everything works under RO4 as it did with the RO4 !Boot.

Who know’s in time there may be things you can only do using RO5!

Topic: Code review / Compressed ROM images

Without network drivers I’m not really sure what the purpose of an IOMD live image would be. Perhaps as an easy way for application developers to check that their software works under RISC OS 5? Or for OS developers to check that the IOMD ROM still works.

They are the two obvious ones for a developer.

But it would give ordinary RPC users the same chance to try RO 5 as non RO users would get on OMAP devices.

e.g. try it out on a club machine.

Topic: Code review / Compressed ROM images

How much ram would an IOMD machine need to have to support a live image type of rom? I know my RiscPC doesn’t have enough.

It all depends on how much you’re trying to squeeze into it. With the OMAP live image the idea is to sell RISC OS to non-users, so you’d need a big image with the full disc image and some bundled software. But for IOMD machines you’d already be softloading ontop of a working RISC OS installation, so all you’d really need is the core boot sequence.

Without network drivers I’m not really sure what the purpose of an IOMD live image would be. Perhaps as an easy way for application developers to check that their software works under RISC OS 5? Or for OS developers to check that the IOMD ROM still works.

Once ROOL have found a way of creating the live images without relying on the hacky LiveDisc component there’s a fair bit of work that could be done to strip out unecessary data from each image. E.g. removing any modules from !System which are already in ROM, dropping high-res sprites from images destined for low-memory machines, etc.

Topic: Code review / Compressed ROM images

How much ram would an IOMD machine need to have to support a live image type of rom? I know my RiscPC doesn’t have enough.

I would hope you’d be able to use it to see what it does in 64MB. I suspect you’d want 96 or 128 for it to really work properly.

RO 5 can access the hard disc

Only if it is on the motherboard interface, as far as I am aware.

The only changes needed are to !Boot so it can cope with the OS in rom or the softloaded OS.

That appears to refer to the ROOL boot, which is fine if you are prepared to replace the original system. But RO 5 on an RPC isn’t really very viable as anything other than a taster yet. The original system needs to remain.

Topic: General / RISC OS on the Raspberry Pi

You don’t need information on the video hardware per se; rather the messaging protocol to the VideoCore coprocessor. Very little of that has been published at the moment. Full information on the USB controller is unfortunately a restricted download and you need a Synopsys SiteID, which in practise means that you must be – like me – working at a semiconductor design company. The Linux driver source is available, of course.

The port is progressing, albeit far slower than I would have liked. I hope to release it to ROOL and Theo soon, so that they may contribute.

Topic: Code review / Compressed ROM images

How much ram would an IOMD machine need to have to support a live image type of rom? I know my RiscPC doesn’t have enough.

RO 5 can access the hard disc, it’s only the lack of networking which is any sort of problem and that won’t change with a live image!

The only changes needed are to !Boot so it can cope with the OS in rom or the softloaded OS.
See this Thread https://www.riscosopen.org/forum/forums/5/topics/899

Topic: Code review / Compressed ROM images

Maybe it would be useful if we made an IOMD live image.

An IOMD live image would be really useful. Currently trying RO5 would require a lot of changes to a RiscPC class machine, which could easily be inappropriate for many systems, and RO 5 might not even support the hard drive controller anyway.

Topic: Code review / Compressed ROM images

I’m not sure how many different ROM sizes the RiscPC supports. I think RISC OS 3.5 was squeezed into a 2MB image, but the only size I’ve heard of being used since then has been 4MB.

It’ll be a while before we overflow the current 4MB IOMD ROM image; there aren’t any USB or SCSI drivers included so there’s tons of space compared to the other ROMs. So we might never need to use compressed IOMD ROMs on a regular basis. I’m mainly adding IOMD support for completeness sake. Maybe it would be useful if we made an IOMD live image.

Topic: Code review / Compressed ROM images

Would it be of any advantage to use compressed ROM for the RPC?

ie can different combinations of ROM’s be used in a RPC – by setting links?
Perhaps using one ROM or more common/cheaper ROMs.

Topic: Code review / Compressed ROM images

However I did need to let the softload tool decompress the Tungsten image and patch the NVidia module; without that patching the ROM didn’t seem to boot at all. Something for me to investigate tonight, although ultimately irrelevant once I’ve moved the patch region into the HAL.

It turns out this is because the HAL patching wasn’t being applied, so the softload-unaware RAM clear code went ahead and nuked the ROM image.

Now that I’ve taught the Tungsten HAL about softloads and differing image sizes the compressed image will boot (with working video), but there’s the slight problem that you get blasted with a brief burst of noise during the HAL initialisation. Strangely this doesn’t happen when booting the uncompressed image, so I’m not sure what the problem is, as the HAL should be behaving in pretty much the same way for both images, and the softload tool should be dumping the images into the same area of RAM each time.

Rather than worry about it too much I think I’ll just make the softload tool turn off sound before booting the image.

Next up will be teaching the IOMD HAL about compressed ROMs, which could be a bit tricky since the RAM isn’t in guaranteed to be in one or two big chunks like on the other platforms.

Topic: Code review / Compressed ROM images

I did think of it at the time, but now that you’ve made me think again I’ve seen a way around the problem that was stopping me from implementing it. Cheers!

(The problem was that the decompression code gets given a pointer to an IMB function, which is really just a wrapper around OS_SynchroniseCodeAreas. Calling a SWI in 32bit mode on a 26bit system is likely to be a no-no, but I didn’t realise that I could just drop back into 26bit mode around the SWI call)

Topic: Code review / Compressed ROM images

gets skipped on 26bit systems anyway [as] the image will have been loaded into a DA, above the 64MB PC limit.

Given the low level nature of the softload tool, can you just set the 32 bit mode bit in the CPSR and run it anyway? The target must be ARM6 MMU or later hence should have 32 bit mode.

Topic: Code review / Compressed ROM images

More progress:

• I think I’ve successfully taught the softload tool about different sized ROM images, and how to detect compressed images. It’s a bit fudgey in places (even more than usual!) but seems to work OK. When loading a compressed image it’ll try to find an area of RAM big enough to hold the uncompressed version, which could help to simplify the implementation of HALs, as well as helping to make sure that you’ve actually got enough memory available to load the image. It’ll also prefer to decompress the image before booting it, but this is optional, and gets skipped on 26bit systems anyway (the tool relies on the decompression code held in the ROM image, but the image will have been loaded into a DA, above the 64MB PC limit).
• Since the softload tool is taking care of ROM placement I’ve successfully managed to boot compressed IOMD & Tungsten images, without having made any HAL changes yet. However I did need to let the softload tool decompress the Tungsten image and patch the NVidia module; without that patching the ROM didn’t seem to boot at all. Something for me to investigate tonight, although ultimately irrelevant once I’ve moved the patch region into the HAL.
• I’ve also made some tweaks to the OMAP HAL (use DMA for relocating the ROM image, go to full CPU speed sooner) which shave about 1.3s off of the compressed live image boot time.

Topic: General / RISC OS on the Raspberry Pi

Abridged BCM2835 datasheet freely available (and a manufacturing date, but let’s face it, the datasheet is the more interesting part ;-))

The datasheet doesn’t contain any documentation about the video hardware and very little about the USB controller, but the bits of hardware which are documented seem to be documented well enough for us to write some drivers. Hopefully it won’t be long before Adrian releases (or is allowed to release) his RISC OS port.

Topic: General / ROMS, ROMS, ROMS

Installed the latest 5.19 ROM today on my BB xM because I started getting freezes with 5.17 as mention earlier in this thread. I stuck with 5.17 because I wanted the save CMOS to SD facility. It still works – presume it was re-instated?

Topic: General / ARM powered notebooks?

With a bit of thought, you start to see ways to adapt RISC OS to a tablet withouth having to put in a vast amount of work

For reference, FX File Explorer uses drags for multiple selections. One question is (when the time’s right) could the corresponding change in Select functionality be added as a configurable ‘Tablet mode’ option in a single ROM? I guess this would be a little more involved but would possibly allow for a(n automatic) switch when a mouse is used.

Topic: Code review / "HELP [" improvements

BASIC I hope? BASICTrans serves no purpose now MessageTrans is around.

Well, it does more than just transfer information from a Messages file and you could not, now, do away with it without adding a lot more to the BASIC module. It is far simpler to alter BASICTrans, because it can be replaced easily. Replacing the BASIC module is problematic.

Topic: Code review / "HELP [" improvements

could easily be incorporated into BASICTrans if needed

BASIC I hope? BASICTrans serves no purpose now MessageTrans is around.

Topic: Code review / NetTime and daylight savings

how does “pick a server automatically” work?

Magic!

Or, more specifically, you can formulate an ‘ntp.org’ timeserver name entirely programmatically by prefixing either the country ISO3166 2 letter abbreviation or the continent. See earlier thread about ISO3166 and recent change to the international module . Live in Oceania? It’s oceania.pool.ntp.org then.