Missing PRM pages.
Matt
them" page 1 - 119. Is there anywhere I can download or get the
omission from? I could really do with them.
Thanking you in advance,
Matt
Peter Naulls
Look here for references to all RO documentation:
Gazza
If you're still looking for it, I've got the OS 3 PRM set, I could e-
mail you a scan if you want.
Jean-Michel
ps.com>
Matt <matt...@live.co.uk> wrote:
Here is a link to Risc Os Select Documentation, but I can send to your
email the PRM1 with the chapitre 10 about interrupts.
http://select.riscos.com/prm/
I have read the thread about operator and new[] syntax, but you dont
get the answer. The thread derives to software developement for Risc
Os. It's a real problem as is the hardware!
Why do you need to overload the new operator ? its job is to allocate
memory from the memory pool.
Your project seem to be interesting : an ARM based 3D engine.
C++ is a good choice if you use the STL Standard templates library
You use container (vector,.....) Exception.
To use with Acorn C/C++ , the Cathlib library works.
http://homepage.ntlworld.com/thouky/software/cathlibcpp/
I use also, OSLib, !Make and !ResEdit
I successed to program a mathematical software I called !PariCalc.
The math side is done in C the original software is Pari, and I build
an interface in C++.
see
http://pagesperso-orange.fr/atelier.jmb/index_/Pt02.htmRISC
Jean-Michel
PS: sorry for my English, correct me please.
--
Jean-Michel BRUCK
jmc....@orange.fr
Europ�en Computer : RISC OS ( Iyonix pc 5.13 & RiscPc (Select))
Peter Naulls
> In message <ba9ffbe0-740c-41fe...@b2g2000yqi.googlegrou
> ps.com>
> Matt <matt...@live.co.uk> wrote:
>
> I have read the thread about operator and new[] syntax, but you dont
> get the answer. The thread derives to software developement for Risc
> Os. It's a real problem as is the hardware!
Actually, he did get an answer - use GCC. If you'd replied to _that_
thread instead of this one as you should have, you might have seen that.
And since this thread was started, a new release has been made:
http://www.riscos.info/index.php?title=Special:AWCforum&action=st/id114/GCCSDK_GCC_4.1.1_Release_2
>
> Why do you need to overload the new operator ? its job is to allocate
> memory from the memory pool.
new is typically overloaded in memory debugging situations, such as
the "fortify" wrappers, and there are some other valid reasons
stemming from general OO principles. But it is also open to much abuse,
as with overriding anything in C++.
> Your project seem to be interesting : an ARM based 3D engine.
I seemed to have missed any references to the project. However,
unless there's some huge advantage to making a new one, surely you'd be
much better off using OpenGL/Mesa. That would be a significant
advantage to RISC OS portability. Whether that was porting extant
libraries, or just implementing the API, etc.
> C++ is a good choice if you use the STL Standard templates library
> You use container (vector,.....) Exception.
Yes, but probably a huge fail if you use CFront, even with:
> http://homepage.ntlworld.com/thouky/software/cathlibcpp/
A valiant effort perhaps, but likely now out of date and incomplete.
Again, use GCC.
Raymond Wiker
> Jean-Michel wrote:
>> Why do you need to overload the new operator ? its job is to
>> allocate memory from the memory pool.
>
> new is typically overloaded in memory debugging situations, such as
> the "fortify" wrappers, and there are some other valid reasons
> stemming from general OO principles. But it is also open to much abuse,
> as with overriding anything in C++.
It may also be necessary to override operator new[] if the
system-supplied implementation is low-quality... probably not a big
issue these days, but I had to do that once back in the early 90s (using
Zortech C under MS-DOS :-)
>> C++ is a good choice if you use the STL Standard templates library
>> You use container (vector,.....) Exception.
>
> Yes, but probably a huge fail if you use CFront, even with:
>
>> http://homepage.ntlworld.com/thouky/software/cathlibcpp/
>
> A valiant effort perhaps, but likely now out of date and incomplete.
> Again, use GCC.
I agree with that - cfront is getting really old, and the
"interesting" bits of C++ didn't really become
standardised/stable/usable until around 2000 (or even later).
Jean-Michel
Peter Naulls <pe...@chocky.org> wrote:
> Jean-Michel wrote:
>> In message <ba9ffbe0-740c-41fe...@b2g2000yqi.googlegrou
>> ps.com>
>> Matt <matt...@live.co.uk> wrote:
>>
>> I have read the thread about operator and new[] syntax, but you dont
>> get the answer. The thread derives to software developement for Risc
>> Os. It's a real problem as is the hardware!
> Actually, he did get an answer - use GCC. If you'd replied to _that_
> thread instead of this one as you should have, you might have seen that.
yes.
> And since this thread was started, a new release has been made:
> http://www.riscos.info/index.php?title=Special:AWCforum&action=st/id11
> 4/GCCSDK_GCC_4.1.1_Release_2
Thanks
>>
>> Why do you need to overload the new operator ? its job is to allocate
>> memory from the memory pool.
> new is typically overloaded in memory debugging situations, such as
> the "fortify" wrappers, and there are some other valid reasons
> stemming from general OO principles. But it is also open to much abuse,
> as with overriding anything in C++.
I think He will only allocate memory for an array ?
>> Your project seem to be interesting : an ARM based 3D engine.
> I seemed to have missed any references to the project. However,
> unless there's some huge advantage to making a new one, surely you'd be
> much better off using OpenGL/Mesa. That would be a significant
> advantage to RISC OS portability. Whether that was porting extant
> libraries, or just implementing the API, etc.
I agree with you, the use of a library is more than an advantage, we
don't need to "r�inventer la roue" (Reinventing the wheel).
Is there a link(s) where we can see a list of those libraries ?
I download the IyonixMesa 3d Accelerator but the demo stops my
Iyonix (new video card and Risc Os 5.13) !
>> C++ is a good choice if you use the STL Standard templates library
>> You use container (vector,.....) Exception.
> Yes, but probably a huge fail if you use CFront, even with:
> > http://homepage.ntlworld.com/thouky/software/cathlibcpp/
> A valiant effort perhaps, but likely now out of date and incomplete.
I have updated it 32bits, and it works on my Iyonix with CFront, but
you have reason it's not very "recent", and due to CFront syntax is
not the standard.
> Again, use GCC.
I think GCC is the good choice and if I have time for programming I
will invest me in GCC, I have already downloaded it.
Happy new year to All
Jean-Michel
Matt
> Look here for references to all RO documentation:
>
> http://www.riscos.info/index.php/RISC_OS_Documentation
Great, found what I need. thanks.
Matt
> Why do you need to overload the new operator ? its job is to allocate
> memory from the memory pool.
My project uses lots of generated code, that I was allocating
using: new uint32 [ codesize ]
When I started my port to Symbian I found the OS would not call
code generated anywhere, but had specific os functions for allocating
memory for creating code in.
So as to change as little existing code as possible I decided to use
the
'new []' operator as below. Fortunately RISC OS allows code anywhere
so i don't have to use the new[] operator in that build.
class arm_instruction
{
public:
# if SYMBIAN
void* operator new [] ( size_t codesize ) { ..allocate using
special symbian os calls }
# if RISCOS or POCKETPC
// nothing. use default malloc
#endifs
uint32 instruction;
};
so now instead of using: p = new uint32 [ codesize ];
I use: p = (uint32*) new arm_instruction [ codesize ];
> Your project seem to be interesting : an ARM based 3D engine.
> C++ is a good choice if you use the STL Standard templates library
> You use container (vector,.....) Exception.
>
> To use with Acorn C/C++ , the Cathlib library works.
> http://homepage.ntlworld.com/thouky/software/cathlibcpp/
STL with cfront? I am surprised.
> I successed to program a mathematical software I called !PariCalc.
> The math side is done in C the original software is Pari, and I build
> an interface in C++.
> see
> http://pagesperso-orange.fr/atelier.jmb/index_/Pt02.htmRISC
>
I will have a look, but what does the program do? Is there english
documentaion?
Matt
Matt
> > Your project seem to be interesting : an ARM based 3D engine.
>
> I seemed to have missed any references to the project. However,
> unless there's some huge advantage to making a new one, surely you'd be
> much better off using OpenGL/Mesa. That would be a significant
> advantage to RISC OS portability. Whether that was porting extant
> libraries, or just implementing the API, etc.
>
OpenGL is really for 3D hardware, and as for Messa running in
software...0.1 fps?
My engine is specifically for the ARM and 'should' run on anything
from ARMv4
upwards that has a 16bit+ display and halfword access (sorry RiscPC )
be it phone, pocketpc, gameboy, nintendoDS or whatvever.
This is because it doesn't use any OS calls, and just writes to a
frame buffer
be it screen memory or a bitmap.
Software ports of graphics engines made for 3D hardware I have seen
are usually
quite slow, but having said that, give it a few years and your average
phone will probably
have 3D hardware!
Anyway watch this space.
Matt
Peter Naulls
>>> Your project seem to be interesting : an ARM based 3D engine.
>> I seemed to have missed any references to the project. However,
>> unless there's some huge advantage to making a new one, surely you'd be
>> much better off using OpenGL/Mesa. That would be a significant
>> advantage to RISC OS portability. Whether that was porting extant
>> libraries, or just implementing the API, etc.
>>
>
> OpenGL is really for 3D hardware,
No, from the Wikipedia article, "is a standard specification defining a
cross-language, cross-platform API for writing applications that produce
2D and 3D computer graphics". OpenGL has been in use for 2D graphics
for as long as I can remember.
> and as for Messa running in software...0.1 fps?
Mesa is simply an open implementation of OpenGL. I don't know where
you made up your figures from, but your solution isn't really
technically different, except that a plain port of Mesa will probably
run slow, yes.
> My engine is specifically for the ARM and 'should' run on anything
> from ARMv4
> upwards that has a 16bit+ display and halfword access (sorry RiscPC )
> be it phone, pocketpc, gameboy, nintendoDS or whatvever.
>
> This is because it doesn't use any OS calls, and just writes to a
> frame buffer
> be it screen memory or a bitmap.
All very well, but extant software uses Mesa for good reason. You seem
to have overlooked what I was saying - you don't have to reuse the Mesa
code, but rather implement the API. But yes, I agree about eschewing
RiscPC support, since half-word access can be important for some types
of graphics operations, and the hardware is now so old.
Jean-Michel wrote:
>
> I download the IyonixMesa 3d Accelerator but the demo stops my
> Iyonix (new video card and Risc Os 5.13) !
>
It's "RISC OS". IyonixMesa is sadly broken on most versions of RISC OS,
including the latest. But you really should upgrade to a later version
in any case. More here:
http://www.riscos.info/pipermail/gcc/2009-November/004972.html
Matt
> Matt wrote:
> >>> Your project seem to be interesting : an ARM based 3D engine.
> >> I seemed to have missed any references to the project. However,
> >> unless there's some huge advantage to making a new one, surely you'd be
> >> much better off using OpenGL/Mesa. That would be a significant
> >> advantage to RISC OS portability. Whether that was porting extant
> >> libraries, or just implementing the API, etc.
>
> > OpenGL is really for 3D hardware,
>
> No, from the Wikipedia article, "is a standard specification defining a
> cross-language, cross-platform API for writing applications that produce
> 2D and 3D computer graphics". OpenGL has been in use for 2D graphics
> for as long as I can remember.
Yes agreed, OpenGL is what it says on the tin. What I really meant,
for 3D at least, is that any software implementation of OpenGL I have
seen
has been lame, and that most people use it for when 3D hardware is
present.
> All very well, but extant software uses Mesa for good reason. You seem
> to have overlooked what I was saying - you don't have to reuse the Mesa
> code, but rather implement the API.
Sorry yes I did overlook what you were saying, implementing the API
may
have been a good idea, and would have made it possible for more ports
to
RISC OS, but I like I said previously, I wanted to make the absolute
most
of the ARM processor, and so decided a dedicated API would be more
suitable.
It's all well and good having an established/portable API, but if it
doesn't run
quick enough to be usable...
> But yes, I agree about eschewing
> RiscPC support, since half-word access can be important for some types
> of graphics operations, and the hardware is now so old.
A big shame though, especially since the processor (well strongarm at
least)
is capable of 32bit mode, and do the halfword access. RiscPC
motherboard
bus upgrade anyone? :)
Matt
druck
> I agree with that - cfront is getting really old,
Getting? It was already really old when Acorn C/C++ was released (95?).
It was a stopgap back in 89-90 before native C++ compilers were widely
developed.
> and the "interesting" bits of C++ didn't really become
> standardised/stable/usable until around 2000 (or even later).
But they were all in compilers at least 5 years before.
---druck
Raymond Wiker
Right... but not generally standardised/stable/usable until
2000 or so. VS 6.0, to take but one example, did not have an acceptable
implementation of stl.
Looks like we're in violent agreement here :-)
Peter Naulls
Yes, but that was still 10 years ago. RISC OS has had a credible
C++ implementation for a long time. G++ has been a superior solution
to CFront in almost all cases since it was released at least 15 years
ago. Let's please put CFront to bed, and drop this silly argument.
Raymond Wiker
I'm *not* disagreeing, dammit :-)
I'm actually a bit surprised that somebody actually wants to use
cfront these days - RISC OS (probably) qualifies as retrocomputing (and
there's nothing wrong with that). cfront, on the other hand, is
necrocomputing.
Jean-Michel
ups.com>
Matt <matt...@live.co.uk> wrote:
> uint32 instruction;
> };
Miles Sabin job, this STL works with CFront, Alexander Thoukydides did
also a good job.
>> I successed to program a mathematical software I called !PariCalc.
>> The math side is done in C the original software is Pari, and I build
>> an interface in C++.
>> see
>> �http://pagesperso-orange.fr/atelier.jmb/index_/Pt02.htmRISC
>>
sorry "RISC" has been append to the URL
http://pagesperso-orange.fr/atelier.jmb/index_/Pt02.htm
> I will have a look, but what does the program do? Is there english
> documentaion?
Yes, I try to explain in english. If you are interested in I can give
sources for the pari 32bits and !PariCalc
But I think it's more "standard" today to use !GCC, I will try it.
> Matt
Jean-michel
Matt
> >>http://pagesperso-orange.fr/atelier.jmb/index_/Pt02.htmRISC
>
> sorry "RISC" has been append to the URL
> http://pagesperso-orange.fr/atelier.jmb/index_/Pt02.htm
>
Yes this link is OK, but the download link on the page is
broken.
Matt
Jean-Michel
ups.com>
Matt <matt...@live.co.uk> wrote:
Sorry I did not try the English version, use the Fench version, it's
the same file.===> "T�l�charger ici (462K Octets)"