A7000+ FPA

Hi all.

Two questions about RISC OS ROMs for RiscPC/A7000.

• Is the hardware FPA used for floating point operations under RISC OS 5.28?
• How much memory RISC OS 5 use on such systems?

Is the hardware FPA used for floating point operations under RISC OS 5.28?

Yes

How much memory RISC OS 5 use on such systems?

A quick test with RPCEmu suggests a fresh install of the disc image will have used about 5MB of RAM by the time the desktop is reached.

If you’re softloading, add 4MB on to that.

No, I plan to change ROMs :)
Thanks for the info.

I modified the RO5 loader to use StubsG – so RO can be loaded from the boot run file without checking the CLib is loaded – speeds the loading a little.

Arrh – NO!

Like Jason Voorhees, the infernal thing Just. Won’t. Die.

Maybe someone needs to make a set of new stubs, one that specifically compiles either old Acorn SharedCLib, newer RO ltd SharedCLibrary, or modern ROOL SharedCLib, with options for version to target so that people can have 3 or 4 versions of there project compiled for use on different systems.

And make sure that if targetting a SharedCLib that does not support newer features, or corrections, that it static links correct updated code for those if used.

No, just no!

If you don’t want the 32 bit SCL, you can’t run 32 bit C programs.

If you do want 32 bit C programs, you use the proper 32 bit stubs and the 32 bit SCL.

There is no other option that can be supported.

If you don’t want the 32 bit SCL, you can’t run 32 bit C programs.

This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This. This.

How many times does it need to be said? Upgrade your library for newer software, or stick with what you have already working.

No other option is sensible.

Expecting developers to nobble their own software to support thirty year old stuff that a user belligerently refuses to update is even less sensible.

In other words what I said:

If you are targetting new systems, use the current SharedCLibrary PERIOD.

If you have a need to ALSO SEPERATELY target older versions, then you need a different set of stubs. NEVER attempt to make a single compile that works on everything, PERIOD.

So as we are agreeing, why the NO statement?

Because what you said here:-

Maybe someone needs to make a set of new stubs, one that specifically compiles either old Acorn SharedCLib, newer RO ltd SharedCLibrary, or modern ROOL SharedCLib, with options for version to target so that people can have 3 or 4 versions of there project compiled for use on different systems.

And make sure that if targetting a SharedCLib that does not support newer features, or corrections, that it static links correct updated code for those if used.

Directly contradicts what you have claimed to have said above.

Directly contradicts what you have claimed to have said above.

Read it again. It clearly says that you should compile only for one version of the SharedCLibrary for a single executable, and that the prefered is the newer. Though if the user wishes to compile for other SharedCLib targets, then maybe someone should provide that ability, so long as they still compile for the more recent versions that are 32Bit.

As one wants to be capable of targetting older SharedCLib versions I will not put limits on that either, as we need every user that wishes to to write software for RISC OS to be allowed to do so, regardless of what they wish to target. If they wish to write for multiple targets, producing seperate AIFs for each SharedCLib target let them as it is what they wish to do.

So there is no contridiction. I Only mention one option to keep as many developers as possible. Still only compile for a single SharedCLib PERIOD. If you want to target older C Libraries I will not stop you, though do it as a seperate compile.