Drobe :: The archives
About Drobe | Contact | RSS | Twitter | Webspace | Tech docs | Downloads | BBC Micro

Profile for adrianl

ContactAbout me
Username: adrianl
Realname: Adrian Lees
About me:
Homepage: www.aemulor.com
Comments posted:129 (show all)

All comments

On First screenshot: Beagleboard runs RISC OS 5 desktop:

It may be best to enable alignment checking in the coprocessor (CP15, c1; A bit) and then fix up unaligned load/stores in a data abort handler to maintain compatibility with precompiled binaries; Norcroft certainly does(/did) use unaligned LDR to access 16-bit quantities and this sort of behaviour change can lead to obscure bugs that are very difficult to track down.

 is a RISC OS Useradrianl on 12/5/09 2:56PM
[ Reply | Permalink | Report ]

On RISC OS 5 spotted running on RPCEmu:

I did get the mouse working....you need *Configure MouseType 0 for quadrature (I didn't recall the correct number at the time). Also noticed the 8MB + 0MB VRAM limitation, which is quite possibly a quick kludge for bring up. The CLZ instructions are readily apparent looking through the ROM image; a quick perusal revealed nothing more, though I may have missed something else by rejecting it as data.

 is a RISC OS Useradrianl on 29/4/09 12:57PM
[ Reply | Permalink | Report ]

On RISC OS 5 spotted running on RPCEmu:

For anyone wanting to try out the ROM on a physical RiscPC, you'll need to remove your VRAM expansion, if present, and modify the 'Ask' utility in the download to (i) ensure that you have CLib 5.46(?) or later loaded before invoking 'SoftLoad' and (ii) use the filename of the actual ROM image downloaded from the site.

After that, my findings are pretty much the same as Tom's...that you can boot to the desktop (although I've not got the mouse working yet), with 8MB DRAM recognised/used, but hardware scrolling is not working, probably because Tungsten doesn't actually use 'true' hardware scrolling, and I'm guessing the previous code is either broken or not properly reinstated.

Overall, very promising.

 is a RISC OS Useradrianl on 29/4/09 2:30AM
[ Reply | Permalink | Report ]

On Click right on with RISC OS:

A few of the more obscure ones:

Shift-double click with the Select button on the icon of an open directory in the Filer, and it closes that directory and all subdirs etc. Use the Adjust button instead and it closes the window you clicked in too.

Ctrl-Alt click on the close icon of any window and it'll close all windows (Tip: do not do this to check your memory whilst actually composing this post in a NS window!).

Ctrl-Alt click on the iconise button of any window will similarly cause all windows to be iconised.

 is a RISC OS Useradrianl on 22/3/08 9:50PM
[ Reply | Permalink | Report ]

On November news in brief:

Yes, that's not a feature of Aemulor, rather of the Iyonix. You really need to set it to draw to a buffer; it does have a dramatic effect upon the speed and playability. Aemulor doesn't support sound (it's technically tricky and didn't get included until later), so you need Aemulor Pro for the full experience. There's no appreciable difference in speed between the two versions, though.

 is a RISC OS Useradrianl on 22/11/07 10:49PM
[ Reply | Permalink | Report ]

On RISC OS-on-Linux first Live CD available:

Stoppers> the drive & disc both work fine from Windows, and the disc can be read on my IYONIX pc. I actually tried deleting the 2nd hard disc partition in this laptop (well, it was empty anyway), but it's still reporting hda /and hdb/ presentation and choosing hdb as before, with the same result, which I don't understand :-s

 is a RISC OS Useradrianl on 6/10/07 12:16AM
[ Reply | Permalink | Report ]

On RISC OS-on-Linux first Live CD available:

Each machine has just one CD-ROM drive (they're actually fairly recent DVD drives). Now that I'm in front of the machine and have tried it again, this is what I get:

... Drive name from proc filesystem: hdb Subdirectory /proc/ide/. Subdirectory /proc/ide/.. Subdirectory /proc/ide/hdb Subdirectory /proc/ide/hda Subdirectory /proc/ide/ide0 Searching for hdb: . .. hdb Matches! Found line for device ide0 Major version number for device ide0 is 3 Probably found CD-ROM Made /dev/cdrom Unable to identify CD-ROM format. Startup failed: Invalid argument

 is a RISC OS Useradrianl on 4/10/07 11:23PM
[ Reply | Permalink | Report ]

On RISC OS-on-Linux first Live CD available:

FWIW, I gave it a whirl too and it looked promising getting past the GRUB loader, displaying Tux and loading a long list of drivers, it located the hard drives, said "Probably found CD-ROM drive" (or similar msg), then stopped with an Unknown CD format which struck me as ironic because it had been successfully booting from the CD up to that point. This is from a CD-RW and I tried it in 2 machines (a '06 cheapo Acer laptop and an old '99 PIII-450) with the same result. Could this be my CD burner software, or do they always burn verbatim?

I'm not very familiar with Linux so haven't looked into it further at the moment, but if there's some way to nudge it past this hurdle having got this far, that'd be great. I'd like to have a play with it, and - no promises just yet - I know about emulation of existing apps, and graphics acceleration, so may have something to contribute?

 is a RISC OS Useradrianl on 4/10/07 7:33PM
[ Reply | Permalink | Report ]


I've often had people remember 'the Archimedes' but not 'RISC OS', unaware that Acorn did anything after that :-/

 is a RISC OS Useradrianl on 29/9/07 2:31AM
[ Reply | Permalink | Report ]

On Early Soundblaster Live Iyonix driver released:

SB0220 SBLive! 5.1 3.3V PCI card

 is a RISC OS Useradrianl on 6/8/07 11:47PM
[ Reply | Permalink | Report ]

On ARM 'security hole' is ofla cousin:

Many embedded CPUs, some ARM-based chips included, do not have a MMU and therefore cannot protect the memory at address 0, leaving the processor vectors vulnerable. RISC OS needn't suffer the same problem because the chips it uses do have full MMUs but it would need work on the kernel and even a few support modules to make (since they have private words at defined addresses within the first 4KB) to resolve this issue properly on all of the processors that it currently supports.

 is a RISC OS Useradrianl on 25/4/07 12:47PM
[ Reply | Permalink | Report ]

On Programming tools set for price slash:

The version of Norcroft C compiler released by Acorn is not suitable for generating code for the XScale core (undefined behaviour of LDR Rd,[Rd],#0 which is its default compilation of LDR Rd,[Rd]). There may be similar issues with other tools in that version of the suite. Of course they also cannot be used on an XScale (at least not without the help of Aemulor).

 is a RISC OS Useradrianl on 26/1/07 11:20PM
[ Reply | Permalink | Report ]

On Castle and ROS Open reveal plans for 2007:

AMS: because RO is leaner and faster, it would start up along with a RO DVD player in much less time than other x86-based OSes, give you a nice user interface that's actually fun to use and still have the required performance to decode DVDs in software where graphics card manufacturers have not made their documentation/drivers public?

To make things perfectly clear, I'm talking about running RO (or a RO-compatible OS) unhosted on x86 hardware, which is very different from emulating it on top of an existing x86 OS such as WinXP or a full Linux + X-Window system. I have no interest in the latter.

 is a RISC OS Useradrianl on 21/1/07 12:32AM
[ Reply | Permalink | Report ]

On Castle and ROS Open reveal plans for 2007:

RO as a desktop platform is just a toy now, we need to migrate to other CPUs and IMHO the way to do this is to gradually recompile and reimplement bits of RISC OS for other architectures, running the bits that have not yet been migrated under emulation along with the applications that have not been rebuilt and/or never will be. I think emulating a full ARM-based machine on a non-ARM platform is a dead end, and sadly I think ARM-based desktop computers are a dead end also. If ROOL releases the whole RO source with the license as described in the article I'd be interested in speeding up the FontManager and that's about it, but with permission to migrate to other hw I'd put in a lot more energy to help migrate RO onto readily-available, higher performance hardware and still pay the license fees to Castle for every sale of RISC OS. I can understand them wanting to protect their hardware sales but I fear those sales are very limited in number now.

 is a RISC OS Useradrianl on 21/1/07 12:23AM
[ Reply | Permalink | Report ]

On Cino DVD player released for free:

There is every chance that it just plain doesn't work on your setup for some reason. It is, at best, alpha quality software, and has likely never been tried on your particular drive/ATA configuration. If memory serves 35 (&23) is just command timed-out so that doesn't tell us very much.

There is one other issue that I've just remembered which is that the region code will need setting on previously-unused DVD drives. I'll try to scribble a few notes to help people avoid the pitfalls but this isn't a finished & supported product. I don't consider Cino to be usable/useful currently.

 is a RISC OS Useradrianl on 29/12/06 1:24AM
[ Reply | Permalink | Report ]

On Cino DVD player released for free:

To play CSS-encrypted VOB files (ie. most files on most commercial DVDs) you need to select it from the Play disc-> submenu in Cino, otherwise it'll just try to play the encrypted data. Since a film often spans multiple VOB files, double-clicking a single file wouldn't work properly anyway.

 is a RISC OS Useradrianl on 29/12/06 12:32AM
[ Reply | Permalink | Report ]

On Iyonix software speed boost driver released:

You get an even better speed increase by not copying large chunks of memory in the first place.

 is a RISC OS Useradrianl on 22/12/06 9:15PM
[ Reply | Permalink | Report ]

On Drobe writer in nuke protest arrest:

bluenose> burning wood releases CO2 that was recently absorbed from the atmosphere. burning fossil fuels releases CO2 that was absorbed millions of years ago from an atmosphere with a much higher concentration of CO2 that would not support human life. That is why fuels such as wood and biodiesel are considered carbon-neutral.

 is a RISC OS Useradrianl on 24/11/06 11:51PM
[ Reply | Permalink | Report ]

On How to create a modern desktop theme:

Gavin> Only the cards recently shipped with IYONIX pcs provide dual screen output and Geminus cannot drive both outputs of a single card yet. The split screen operation that you have seen with Geminus is achieved simply by having multiple cards in the machine.

 is a RISC OS Useradrianl on 06/10/06 12:36AM
[ Reply | Permalink | Report ]

On RISC OS Open needs your help:

mrchocky> STD's current ROM image does not even protect zero page from USR mode writes, never mind reads. This is something that I sincerely hope will be changed soon.

 is a RISC OS Useradrianl on 5/10/06 11:46PM
[ Reply | Permalink | Report ]

On RISC OS 5 source code release revealed:

>It's not as if their going to release the real meat of RISC OS ( kernel, WIMP etc.) so that you could effectively compile your own RISC OS

Is that your conjecture? The FAQ on the site clearly states that the release will be phased and the software components listed are merely the first phase, to test the waters. They are the easiest for people to build and work on too.

 is a RISC OS Useradrianl on 01/10/06 1:03PM
[ Reply | Permalink | Report ]

On RISC OS 5 source code release revealed:

> I guess all those Linux-based devices are purely imaginary, then.

I was thinking of products that are purely software. It's a little more difficult to copy and distribute hardware.

 is a RISC OS Useradrianl on 30/9/06 3:35PM
[ Reply | Permalink | Report ]

On RISC OS 5 source code release revealed:

> Anyway, the "shared source" licensing of RISC OS "Open" seems like an odd combination of GPL-like distribution terms with a commercial exploitation restriction. It'll be interesting to see what effect that restriction has, and whether the GPL won't ultimately prove to be a better choice.

I'd argue that since GPL in /practice/ if not in letter prevents the code being used in commercial products, that the proposed dual-licensing arrangement (at least as currently outlined) is actually more flexible.

 is a RISC OS Useradrianl on 30/9/06 3:28AM
[ Reply | Permalink | Report ]

On Intel wheels out 1.2GHz XScale family:

Well, that's what happens when you misuse chips that have been designed for something else.

 is a RISC OS Useradrianl on 28/9/06 1:15PM
[ Reply | Permalink | Report ]

On RISC OS 4 kernel caught on Iyonix:

It now has working mouse input, IDE, CMOS RAM, screen and HostFS which leaves the keyboard, sound (not really supported by RPCemu currently) and network (again, not yet available). Then it needs a whole lot of optimisation.

 is a RISC OS Useradrianl on 28/9/06 12:12PM
[ Reply | Permalink | Report ]

On CinoDVD project paused:

cables> Probably because you wrote something people don't want to read. Fwiw, I agree that RO's limitations are painfully obvious after using another platform but I still have a number of reasons for preferring RO. Cino's status hasn't changed over the past couple of years. Really this article is just a 'status report' in response to the question raised on the newsgroups.

In fact, I wrote some test code recently which I think demonstrates that 25fps playback at DVD resolution is possible on the Iyonix, but it will take a lot of work to tune the software to that level. The IOP321's memory bus isn't really adequate for implementing motion compensation in software. That doesn't prevent more appropriate hardware being employed, but it does make it even more of a niche product.

There's a lot of code in Cino that could find use elsewhere - the DVD filing system works with CD-ROMs, audio CDs and DVD-ROMs, the AC3 decoder is faster than the fairly basic port currently employed by KinoAMP, the overlapped DMA to screen is already used by Geminus and likely soon by NetSurf/Tinct, the optimised MPEG decoder has multiple other uses (once fixed ;) as has already been noted. DeCSS and authentication with the DVD-ROM drive etc etc. What happens to it all is something I haven't yet decided.

Personally, I think the fact that I can no longer spend the bulk of my development time writing RO software is a sadder reflection of the platform than the fact that Cino hasn't materialised on the (somewhat performance-limited) hardware that we have available.

 is a RISC OS Useradrianl on 24/8/06 4:18PM
[ Reply | Permalink | Report ]

On Dual core 1.2GHz Xscale touted by Intel:

Data that needs to be accessible to I/O hardware such as DMA controllers might need to reside in main memory as opposed to L1/L2 cache, it depends upon the architecture. Likewise, for some systems you can just use cache memory as a replacement for main memory. In fact the XScale core used in the Iyonix allows you to do exactly that. You need to write some special code to allocate the cache lines to the addresses you want your 'pseudo-RAM' and then lock those lines in the cache. Hey presto, very fast RAM that makes all other memory accesses that little bit slower by reducing the amount of cache space available to them ;)

 is a RISC OS Useradrianl on 23/8/06 5:10PM
[ Reply | Permalink | Report ]

On Castle considering open sourcing RISC OS:

JGZimmerie> Perhaps because their business relies upon selling ARM-based hardware that runs RO? Were somebody to modify RO to run, by whatever means, on other hardware, they run the risk of losing a big part of their income.

 is a RISC OS Useradrianl on 23/08/06 04:10AM
[ Reply | Permalink | Report ]

On Castle considering open sourcing RISC OS:

No, but it could be extended if necessary, and in a backwards compatible manner.

 is a RISC OS Useradrianl on 20/08/06 03:15AM
[ Reply | Permalink | Report ]

On Castle considering open sourcing RISC OS:

jess> Both. It clearly makes sense to run a native build where available but ARM executables must be supported so that we can run what software we do have, and that definitely includes modules such as bits of the OS that have not been converted.

 is a RISC OS Useradrianl on 20/08/06 02:23AM
[ Reply | Permalink | Report ]

On Castle considering open sourcing RISC OS:

fwiw, here's my opinion:

RO only runs best on ARM because it can't run natively on anything else. I would happily see it ported to run natively on other hardware, which in practice means (or at least includes) Intel's x86 line because its cheap, readily available and - importantly - is much faster than any ARM-based hardware.

If RO, or at least the key parts, were open sourced then it could save a lot of time by allowing porting rather than complete reimplementation, or at the very least serve as a reference implementation to answer the "what does RO do in this case?" questions without writing a lot of test code.

With a dwindling market making commercially viable development impossible, and us programmers only able to chip in with what we can do in our spare time, I believe it's our best path forward.

 is a RISC OS Useradrianl on 19/08/06 8:50PM
[ Reply | Permalink | Report ]

On ROS must open up to survive says Wild:

AMS> The speed loss you anticipate from converting to a high level language is far from obvious to me. In fact, in a high level language, programmers are more willing to use improved algorithms and to improve the existing code. Furthermore, by running the code through a new compiler, all code can be tuned for a new processor pipeline (particularly important on the XScale, and even StrongARM). This is something that still hasn't - and almost certainly never will - be done for much of RO's assembler code because it would be a lot of work.

Whilst there may not be enough developers out there to make dramatic improvements to RISC OS, were it ever open sourced, they are still a superset of the developers that have tried to work on it commercially over the past few years, many of whom have been forced to depart.

 is a RISC OS Useradrianl on 20/07/06 11:23PM
[ Reply | Permalink | Report ]

On ROS must open up to survive says Wild:

Jwoody> maybe so, but would you say that commercial development of RISC OS or its applications over the same time period /has/ 'covered itself in glory?' Open sourcing may well be a long way from the ideal scenario, yet still be an improvement.

 is a RISC OS Useradrianl on 19/7/06 7:12PM
[ Reply | Permalink | Report ]

On Ex-Pace staff back RISC OS Open Ltd:

bucksboy> Indeed, but do you really need any more proof that it's not viable _commercially_?

 is a RISC OS Useradrianl on 10/7/06 6:19PM
[ Reply | Permalink | Report ]

On Geminus gains accelerated JPEG support:

The update, version 1.31, is now on the site. See the 'My software' page if you've already downloaded a copy.

 is a RISC OS Useradrianl on 30/3/06 10:06AM
[ Reply | Permalink | Report ]

On Geminus gains accelerated JPEG support:

I've resolved the problem with JCut, see the support forums for more info. An update to Geminus will be available shortly, once I can be reasonably confident that any other problems identified with the first release have been resolved.

 is a RISC OS Useradrianl on 27/3/06 12:41AM
[ Reply | Permalink | Report ]

On South West 2006 round up:

If you want something to worry about wrt Geminus on Iyonix Select, make it the latter rather than the former. Geminus could as surely be made to work on Select as on RISC OS 5, it's just software.

 is a RISC OS Useradrianl on 20/2/06 7:45PM
[ Reply | Permalink | Report ]

On Castle rattles licensing sabre at 32bit RISC OS 4:

arawnsley> Whilst APCS-32 code generated by Norcroft 5.06 may appear 32-bit safe, and sometimes work, it can fail unpredictably because the compiler will generate the instruction LDR Rd,[Rd],#0 which is UNDEFINED in the ARM architecture and can crash on the XScale (I believe its action depends upon whether the memory for that address has been cached and will thus sometimes work as intended, sometimes not.)

 is a RISC OS Useradrianl on 20/01/06 10:28PM
[ Reply | Permalink | Report ]

On Geminus graphics acceleration launched:

The code is believed to work on later NVidia cards, although - as with everything NVidia-related - I have no documentation. Geminus does have a SWI interface but it's not yet complete and is thus not documented publically. Originally it was intended only to allow applications such as Cino and PCITV to commandeer extra screens for their own use, but it would be nice to extend the API to make the acceleration directly available to applications where there is no suitable OS API.

 is a RISC OS Useradrianl on 13/12/05 10:18PM
[ Reply | Permalink | Report ]

On Geminus graphics acceleration launched:

Sprite plotting and cacheing will work outside the desktop too, although many apps that run outside the desktop will just manipulate the screen directly and thus can't be readily accelerated.

Obviously redraw cacheing is specfic to the desktop environment.

 is a RISC OS Useradrianl on 13/12/05 4:24PM
[ Reply | Permalink | Report ]

On Geminus graphics acceleration launched:

ROHC> Filer speediness? Explain please.

highlandcattle> Tematic/Castle wrote a driver that makes the card work but also does rectangle copying and solid filling in hardware (you'd find the machine unusably slow otherwise)

Simon ported the 3D driver and OpenGL-compatible library. There are presently no 3D programs for the IYONIX pc/RISC OS capable of using this :(

Geminus uses the 2D hardware acceleration more extensively with the aim of making the desktop more responsive and doing so without requiring applications to be modified. Geminus does still require the Tematic/Castle driver for setting up the screen and defining/moving the mouse pointer but does everything else itself.

 is a RISC OS Useradrianl on 11/12/05 6:28PM
[ Reply | Permalink | Report ]

On Geminus graphics acceleration launched:

I can't make promises on that score, I'm afraid. It shouldn't be very much extra work to make the redraw cacheing work properly on the RiscPC again (that is where it started out) and thus on the A9home*, but there is also the small matter of a DVD player that I want to finish ;)

* the code does actually work on both, but it needs improvement and some small corrections.

 is a RISC OS Useradrianl on 11/12/05 4:16AM
[ Reply | Permalink | Report ]

On Geminus graphics acceleration launched:

There's still a good bit of room for improvement, yes. I've actually disabled a couple of features in the current release because I'm not yet convinced of their stability.

 is a RISC OS Useradrianl on 10/12/05 11:53PM
[ Reply | Permalink | Report ]

On Geminus graphics acceleration launched:

Sprite cacheing is something that's unlikely to be useful on the RiscPC because there's no hardware capable of copying cached sprites to the screen quickly. I think you mean redraw cacheing, which remembers the contents of windows so that they can be redrawn quickly.

This does make a big difference for slower apps on the RiscPC, with all processors from ARM610 through to StrongARM.

Some other improvements may be attainable using some of the Geminus code but the OS code is a better match to the hardware of the RiscPC and earlier machines than it is to the IYONIX pc (it hasn't been updated substantially), so any gains will likely be smaller.

 is a RISC OS Useradrianl on 10/12/05 4:44PM
[ Reply | Permalink | Report ]

On Geminus graphics acceleration launched:

AMS> The A9home does have some off-screen memory that can be used for cacheing sprites and window contents, albeit only a total of 8MB video memory versus the 64MB on the NVIDIA cards (32MB on older cards).

I intend to add support for extra cache in main RAM too, because the A9home has limited memory (and even the NVIDIA card's memory can seem limited in high res screens) and because the RiscPC version will require it.

 is a RISC OS Useradrianl on 9/12/05 8:06PM
[ Reply | Permalink | Report ]

On Geminus graphics acceleration launched:

highlandcattle> much of the code is not specific to the GeForce2. In fact Geminus already includes driver code for GF2, SM501 (used in the A9home) and VIDC20 (RiscPC).

 is a RISC OS Useradrianl on 9/12/05 1:30PM
[ Reply | Permalink | Report ]

On Geminus graphics acceleration in beta:

Not for the acceleration code, no. The multi-screen and rotation features constrain the widths to certain values.(256n pixels)

 is a RISC OS Useradrianl on 9/11/05 12:46PM
[ Reply | Permalink | Report ]

On Voice-over-IP on RISC OS: What's involved?:

Personally, yes, because I would most likely be using VoIP to talk through and diagnose any problems encountered with my software, so I would be using the computer for other tasks at the same time.

Loading large files, though, was just an easy illustration; I'm quite sure that other situations when this problem would occur. One even more obvious illustration, with RO as it stands, is clicking on the icon of an empty CD-ROM drive whilst there's music playing.

 is a RISC OS Useradrianl on 31/10/05 5:42PM
[ Reply | Permalink | Report ]

On Voice-over-IP on RISC OS: What's involved?:

My point is that some of the work must be done on callbacks with RO as it stands because you can't call the Internet module to read audio data from the IP stack in an IRQ handler.

Certain operations, such as loading a large file, or even lengthy graphics operations, cause the OS to spend a long time in SVC mode, preventing callbacks from occurring. The issue is not with IRQ latency, rather callback latency which cannot exceed 150ms, give or take, without affecting quality.

I think that's achievable - though as Martin says, probably not easy - for a singletasking client, but I also think it will break up badly when used in the desktop alongside other activities. Personally that's not a product I'd be prepared to build and sell.

You are, of course, free to prove me wrong.

And for the record, Chris is more or less quoting my opinion, so don't blame him ;)

 is a RISC OS Useradrianl on 31/10/05 2:08PM
[ Reply | Permalink | Report ]

On Voice-over-IP on RISC OS: What's involved?:

wuerthne> ShareFS is not a real-time system; if the data arrives just 500ms late it doesn't matter. If audio data arrives late or isn't decompressed promptly then the distortion is very noticable and equally distracting.

For one-way playback of CD audio, MP3s and DVD, for example, the usual workaround is to have a large buffer and to slightly delay playback with respect to the incoming data. This, of course, is not a workable solution for a two-way conversation which requires low latency.

I believe that in the present RO multitasking environment and/or the presence of background activity such as ShareFS network traffic, a VoIP client will not perform well unless driven from a periodic IRQ with RO as it stands. For example, loading a multi-megabyte file into memory is sufficient to break up or halt audio that relies upon CallBacks.

 is a RISC OS Useradrianl on 31/10/05 5:30AM
[ Reply | Permalink | Report ]

On A9home compatibility list open for all:

sa110> It can also give the illusion of working but lead to essentially unpredictable failures whilst the application is running, or only when a particular action is performed. If you're aware of that caveat, fine, but there's a risk that such faults will be attributed to the wrong bit of software, or even the hardware.

Only the software developer, or someone with the time and inclination to pick apart the binary, really knows whether the application requires the extra functionality of the Castle CLib module, or is - perhaps accidentally - dependent upon it oweing to (possible) divergence between the ROL and Castle modules.

 is a RISC OS Useradrianl on 18/10/05 12:10AM
[ Reply | Permalink | Report ]

On Hifi buffs told Iyonix audio is good enough:

A thought just occurred to me - someone with IYONIX Linux installed might like to try audio playback with that OS to see whether the crackling still occurs. If possible I'd suggest playing WAV files from memory rather than decoding and playing MP3 files, to keep things simple.

I wonder whether it might be IRQ latency that's causing the audio to break up momentarily; I've certainly heard the audio stop/break up very badly when an application fails and the OS maps the whole task into memory.

With RO being structured as it is, there is - sadly - also the chance that the MP3 decoding routine isn't be called promptly enough, merely because the OS is spending a lot of time in SVC mode. Hence my suggestion that playing a WAV file from RAM be used as the test.

 is a RISC OS Useradrianl on 11/9/05 3:52PM
[ Reply | Permalink | Report ]

On Is this the widest RISC OS desktop yet?:

druck> we've suggested a change to Castle for inclusion into the NVidia module. If/when implemented that should allow Geminus to be modified so that the 256-pixel constraint does not apply on the leftmost and rightmost screens; since you'd only have 2 screens, this should allow the object of your desire to be used.

 is a RISC OS Useradrianl on 6/9/05 3:11PM
[ Reply | Permalink | Report ]

On Is this the widest RISC OS desktop yet?:

hEgelia> I just wanted to be sure that the code worked with more than 2, as I'd intended. There's a lot of unreleased work already been done on Geminus that we feel is likely to benefit more users than the multi-screen support, especially the hardware acceleration and cacheing techniques which really do make the desktop feel a lot faster. I acquired the 3rd card to investigate some problems with that code.

Cino's completion and release hinges upon being able to wring enough performance out of a CPU and, especially, memory system that's really not intended for anything as computationally intensive as DVD decoding/playback.

We're not waiting upon Castle for any of Cino's development. Just me. :|

For what it's worth, I just tried Geminus at 3 x 2048 x 1024 (total screen size = 24MB which is the limit in current releases of Geminus) and that works too, although my LCD panels obviously can't display all the pixels ;)

 is a RISC OS Useradrianl on 6/9/05 10:17AM
[ Reply | Permalink | Report ]

On Oregano, Firefox and NetSurf reviewed:

SimonC> re Oregano 1 under Aemulor, it's most likely that you just need to patch the HTTPStream module as documented here:


There's some code in that module which isn't strictly SA/XScale-compatible.

 is a RISC OS Useradrianl on 26/8/05 9:33PM
[ Reply | Permalink | Report ]

On Firefox beta 3 released:

hzn> you can iconise it to the pinboard (shift-click on the Close icon) or the iconbar (use the Iconise icon, after enabling it in the Windows pane of Configuration) in the same way as for any other window.

 is a RISC OS Useradrianl on 24/7/05 7:43AM
[ Reply | Permalink | Report ]

On Delving inside an A9home:

The serial port is, I imagine, just a connector on the back panel with a ribbon cable to the black 10-pin IDC socket that you see far left in the first picture.

 is a RISC OS Useradrianl on 25/6/05 11:00PM
[ Reply | Permalink | Report ]

On Firefox first beta published:

Just the readily-available version 1.85 at the moment, I'm afraid. We'll have to wait and see what Thomas has to say, I suppose.

 is a RISC OS Useradrianl on 23/06/05 4:09PM
[ Reply | Permalink | Report ]

On Firefox first beta published:

SimonC> I converted LIRC to 32-bit yesterday, following your prompt. Am awaiting a response from Thomas wrt its distribution.

 is a RISC OS Useradrianl on 23/06/05 1:33PM
[ Reply | Permalink | Report ]

On Firefox first beta published:

sa110> I should point out that only the ARM610 engine of Aemulor currently works on the A9home since the JIT phase is incomplete, so the speed you're seeing with Fresco is less than impressive.

 is a RISC OS Useradrianl on 21/06/05 11:57PM
[ Reply | Permalink | Report ]

On Firefox first beta published:

1st post, from an A9home, running the FireFox beta :P

 is a RISC OS Useradrianl on 20/6/05 2:15PM
[ Reply | Permalink | Report ]

On Expo 2005 show report:

spellinn> Well, I'll admit I thought he meant you and Ina for a second, but look at the photo again!

 is a RISC OS Useradrianl on 20/6/05 2:09PM
[ Reply | Permalink | Report ]

On 32bit Adjust on ARM9 breakthrough:

I've only looked through the datasheets quickly, but I think the answer is - sadly - no for the StrongARM engine. (Most of the features needed are in fact present, just not the breakpoint registers)

Having said that the JIT - if I ever finish it ;) - will, and the ARM6 interpreter of course.

 is a RISC OS Useradrianl on 11/10/04 7:04PM
[ Reply | Permalink | Report ]

On 32bit Adjust on ARM9 breakthrough:

SA does support 32 bit. As do all CPUs from the ARM6 upwards, in fact.

I can't imagine RO Ltd wanting to keep two lines of code (26- and 32-bit) running but I reserve the right to be wrong.

 is a RISC OS Useradrianl on 11/10/04 03:49AM
[ Reply | Permalink | Report ]

On MicroDigital tout big RAM for Omega:

i was pleasantly surprised with the rendering speed of ArtWorks on the A6/VRPC at Wakefield. However, I wouldn't take it as a representative average because the rendering is done by short loops that get executed a lot. JITs such as VRPC handle this well, as does the StrongARM engine in Aemulor; hence the big speed increase from ARM610->SA.

As with any emulator, some operations will be faster, some slower. To me the A6 I tried didn't feel nearly as slick as the Iyonix but unfortunately there wasn't much software on the machine to get a better feel for its speed.

 is a RISC OS Useradrianl on 11/07/04 8:31PM
[ Reply | Permalink | Report ]

On Castle spills beans on ROL dispute:

Jeff: If RO5 is made available for RPC-era machines, it shouldn't actually be necessary to emulate old program code because the 26-bit CPU modes are still available. It will, however, be necessary to hide the API changes & handle 26-bit modules which is the major part of Aemulor's work. See here: [link] where I tried to explain the issues a couple of days ago.

 is a RISC OS Useradrianl on 22/06/04 01:44AM
[ Reply | Permalink | Report ]

On Castle opens RISC OS future wishlist:

> units all be the full version of RO5 as found in the Iyonix? No. The core stuff would undoubtedly be largely unmodified and most RO5 apps could presumably be used with little or no modification. Since the I/O capabilities would differ from those of the Iyonix, different driver modules would be present and those which aren't required would be omitted, just as they are in the Iyonix RO5 which has no PS2Keyboard, Econet, MIDI or Joystick modules, for example.

 is a RISC OS Useradrianl on 21/05/04 01:40AM
[ Reply | Permalink | Report ]

On MicroDigital owners club sees light of day:

>i've seen a simple non-desktop BASIC program that uses POINT x,y to generate a texture that can stiff a machine...

Did that program get sent to Castle? If it fails with any regularity it would be a godsend in tracking down any reliability issues.


 is a RISC OS Useradrianl on 19/12/03 10:19PM
[ Reply | Permalink | Report ]

On Again with the laptops:

Yeah, it's a RISC pretending to be a CISC, pretending to be a RISC.

Hmmm.... efficient! Begs the question what Intel could do if they got their speed-centric x86/Itanium team working on the XScale core.


 is a RISC OS Useradrianl on 07/12/03 11:10AM
[ Reply | Permalink | Report ]

On Please Stop the Madness:

> Although Axel hasn't replied to complain - well he probably has

Well, I for one, have received an email from him and he is upset about his email being treated in the way it has been.

What saddens me though is that you, me, Axel and Drobe all want the same thing. We want RISC OS to grow and prosper. Perhaps we all need to be a bit more careful about how we express ourselves.


 is a RISC OS Useradrianl on 11/11/03 10:26PM
[ Reply | Permalink | Report ]

On Castle FAQ on RISC OS buy out:

Personally I'd love to see RO5 'ported' back to the RiscPC/A7K, if only for environmental reasons - I don't like the idea of old machines being thrown out if they are fast enough to perform the desired task - sadly most machines are thrown out because software has become less efficient.

But I think our chances of seeing an OS that can run 26-bit only, 26-/32-bit neutral AND 32-bit only code are virtually nil. RO5 only runs apps that fall into the latter two categories.

Which means that if you upgraded your RiscPC to this theoretical RO5 you would lose the ability to use those apps which are still 26-bit, eg. Impression, Sibelius, Eureka, PipeDream plus (from our feedback @ Aemulor) many lesser-known but still frequently-used apps.

You would need something akin to Aemulor that would switch the StrongARM back into 26-bit mode in order to run the 26-bit-only module/app code and then wrap SWI calls etc so that they provide the old behaviour as per RO4, eg. flag preservation and undoing the API changes that have been made in RO5...plus, callbacks from the OS to the 26-bit code would need wrapping so that the SA is switched back to 26-bit mode...

From experience I can tell you that this is no small amount of work.

For those of you who are wondering "why can't we just run RO5 + Aemulor" on our RiscPCs, Aemulor relies upon hardware features that're unique to the XScale processors...ie. not present on the StrongARM; it wouldn't be possible to emulate 26-bit code at the same speed in the StrongARM's 32-bit mode (at least, not without a radically better approach that I haven't yet thought of! ;-)

> Could the work done in Aemulor be used to allow current MT apps to run in a new PMT RISC OS?

Yes it could.... or, at least, it would help if your apps are 26-bit RO ARM code & your OS isn't ARM-based, in the sense that Aemulor provides a fair wodge of RO functionality but in portable code (C)...but, to be fair, even the latest x86 hardware can't run ARM code at speeds comparable with native hardware, with the current emulators anyway.

More directly, the problem with making a new PMT RISC OS has less to do with the apps, and more to do with the WindowManager, FileSwitch & other filing system modules plus, of course, the RISc OS kernel..... and then, after you've got that lot working, you run into 'trivial' stuff like system variables which, traditionally, have global scope and yet Obey$Dir - for example - will almost certainly cause things to break.

Adrian www.aemulor.com

PS. If ever you run out of hope, remember some folks are idiots and do things for free! ;-)

 is a RISC OS Useradrianl on 20/07/03 03:36AM
[ Reply | Permalink | Report ]

Search the archives

Today's featured article

  • CDs Available
    Drobe Special Projects
     2 comments, latest by piemmm on 21/10/03 12:23PM. Published: 23 Jul 2003

  • Random article

  • Firefox 2 install guide published
    Coders should spend time on fixing faults says porter
     14 comments, latest by jess on 18/3/07 9:18PM. Published: 10 Mar 2007

  • Useful links

    News and media:

    Top developers:
    RISCOS LtdRISC OS OpenMW SoftwareR-CompAdvantage SixVirtualAcorn

    CJE MicrosAPDLCastlea4X-AmpleLiquid SiliconWebmonster


    RISCOS.org.ukRISCOS.orgRISCOS.infoFilebaseChris Why's Acorn/RISC OS collectionNetSurf

    Non-RISC OS:
    The RegisterThe InquirerApple InsiderBBC NewsSky NewsGoogle Newsxkcddiodesign

    © 1999-2009 The Drobe Team. Some rights reserved, click here for more information
    Powered by MiniDrobeCMS, based on J4U | Statistics
    "Who cares? I, for one, rarely go to drobe..."
    Page generated in 0.4328 seconds.