Photodesk and 32-bit.
Kell Gatherer
!OHP from the same company.
I was at the ROUGOL meeting on Monday night where Jack Lillingston
presented Iyonix. PhotoDesk was mentioned, and various comments were made,
including (from the crowd):
"I heard that it can't be done now that Chris lost his programmer."
Jack:
"Yes, it turns out not to be written in C."
"It's more than half assembler."
"It would be a huge amount of work."
"Probably easier to start again."
but the sentence that worried me the most (from Jack):
"We are aware we have to do something about that, because the platform
really must have a bit-image editor."
I had my hand on my wallet about to buy an Iyonix, but when I heard that I
stopped.
Today I've had a look at the !PhotoDesk code:
The !RunImage file is BASIC, and there is a large module called
"Photodesk" in the 'modules' directory. Armalyser declares there is 0.2%
of the module code that is not 32-bit neutral. You would have thought,
therefore, that !PhotoDesk could be released for Iyonix.
However, weeks have now gone past without an announcement, which leads me
to suspect that there is a problem behind the scenes. Perhaps when Chris
'lost his programmer' he took the source code with him?
And now I've heard that Chris Hornby, at the Motorcycle Museum (30th
November), when pushed, said "a 32-bit PhotoDesk is unlikely to happen".
I use my RPC for lots of different things, the one thing I use it for
which is the most processor-intensive is !PhotoDesk, which moves around a
lot of data. This is *the* application which would most benefit from being
'ported' to the Iyonix. Also for sure it would be a chargeable upgrade
which would benefit PhotoDesk Ltd immensely.
Why the silence? Whatever the truth, it is better that we know.
...and if anyone knows better, please put me out of my misery!
--
Kell Gatherer
ke...@locsource.com
The Location Source
James Sargent
> Why the silence? Whatever the truth, it is better that we know.
>
> ...and if anyone knows better, please put me out of my misery!
Did you send this to Chris @ Photodesk - have you phoned and asked him
or emailed him?
Regards,
James
John Pettigrew
> Silence about PhotoDesk
[snip]
> This is *the* application which would most benefit from being 'ported' to
> the Iyonix. Also for sure it would be a chargeable upgrade which would
> benefit PhotoDesk Ltd immensely.
I was told, when I asked that it "worked fine with Aemulot" [sic], which
suggests to me not to hold my breath.
Shame - and possibly a good reason to buy an Omega instead...
John
--
John Pettigrew Headstrong Games
john at headstrong-games.co.uk Fun : Strategy : Price
http://www.headstrong-games.co.uk/ Board games that won't break the bank
Valley of the Kings: ransack an ancient Egyptian tomb but beware of mummies!
The Doctor
John Pettigrew <jo...@NOT-RELEVANT.headstrong-games.co.uk.INVALID> wrote:
> In a previous message, Kell Gatherer wrote:
>
> > Silence about PhotoDesk
> [snip]
> > This is *the* application which would most benefit from being 'ported' to
> > the Iyonix. Also for sure it would be a chargeable upgrade which would
> > benefit PhotoDesk Ltd immensely.
>
> I was told, when I asked that it "worked fine with Aemulot" [sic], which
> suggests to me not to hold my breath.
>
Unfortunately PhotoDesk benefits greatly from as fast a processor as is
possible.
Running it under emulation would be a definate backwards step.
It gets worse though.
APDL seem to be very uninterested in converting the software they sell
to 32bit.
This covers the Pineapple ArtStudio24 packages which they took over
development of sometime ago and now more recently the Clares
ProArtisan24 which is also covered by APDL since they took over the
development and distribution of all Clares Micro supplies software.
> Shame - and possibly a good reason to buy an Omega instead...
>
If the Omega is a big enough improvement over the RiscPC...
Cheers!
--
Graham
The RISC OS software site - www.thedeathzone.free-online.co.uk/software
The RISC OS hardware guide - www.thedeathzone.free-online.co.uk/hardware
Deathzone Emulation - www.thedeathzone.free-online.co.uk/emulation
The Main Control Room - www.thedeathzone.free-online.co.uk
James Sargent
> APDL seem to be very uninterested in converting the software they
> sell to 32bit.
I wonder if it's uninterested or unabled. APDL sell these packages, many
of which are from people / companies who are no longer around. Do they
have the programmers available to conver them?
James
John Pettigrew
> In message <dd1ac3a...@xl-cambridge.com>
> John Pettigrew <jo...@NOT-RELEVANT.headstrong-games.co.uk.INVALID> wrote:
>
> > I was told, when I asked that it "worked fine with Aemulot" [sic], which
> > suggests to me not to hold my breath.
> >
> Unfortunately PhotoDesk benefits greatly from as fast a processor as is
> possible. Running it under emulation would be a definate backwards step.
That's my feeling, too - we're told that Aemulor/Iyonix runs progs at about
the speed of a RiscPC600, which is a *lot* slower than SA.
However, we're also told that Omega prototypes run about 2-3 times the speed
of an SA RPC (without any gfx acceleration), so that is definitely
worthwhile - Photodesk should gain somewhat from the ~10-30% faster
processor (287 vs 233 MHz SA), but should gain a lot from the *much* faster
bus. I'd definitely expect it to be a worthwhile upgrade.
Which means that, if Castle want to sell *any* Iyonixes to serious graphics
users, they will *have* to fund the conversion of at least one of the 3 main
bitmap packages to 32-bit. Otherwise it will be an automatic victory to the
Omega, even without an XScale.
John
--
John Pettigrew Headstrong Games
john at headstrong-games.co.uk Fun : Strategy : Price
http://www.headstrong-games.co.uk/ Board games that won't break the bank
Knossos: escape the ever-changing labyrinth before the Minotaur catches you!
Steffen Huber
> In a previous message, The Doctor wrote:
> > In message <dd1ac3a...@xl-cambridge.com>
> > John Pettigrew <jo...@NOT-RELEVANT.headstrong-games.co.uk.INVALID> wrote:
> >
> > > I was told, when I asked that it "worked fine with Aemulot" [sic], which
> > > suggests to me not to hold my breath.
> > >
> > Unfortunately PhotoDesk benefits greatly from as fast a processor as is
> > possible. Running it under emulation would be a definate backwards step.
>
> That's my feeling, too - we're told that Aemulor/Iyonix runs progs at about
> the speed of a RiscPC600, which is a *lot* slower than SA.
It depends. The current development version of Aemulor is able to emulate
ArtWorks at around ARM610 speed, this is probably the only thing we know
for sure at the moment.
This is pretty much the worst case for Aemulor - no clever optimizations
built in yet, and a piece of software that spends nearly 100% of its time
outside the OS.
I think it is not at all clear what performance we might expect from
specific software running under optimized versions of Aemulor. I would
expect software like e.g. Browse to run at SA speed. Photodesk might
profit from the much faster Disc I/O once it starts to swap. We just
don't have any figures available atm.
> However, we're also told that Omega prototypes run about 2-3 times the
> speed of an SA RPC
Some applications. Not all. See Aemulor ;-)
> (without any gfx acceleration),
Which wouldn't help Photodesk anyway, if it can never be changed again to take
advantage of gfx acceleration (if it could, a 32bit version could be
produced anyway).
> so that is definitely worthwhile - Photodesk should gain somewhat from
> the ~10-30% faster processor (287 vs 233 MHz SA),
IIRC, Omega is specified with a 300 MHz StrongARM.
> but should gain a lot from the *much* faster
> bus.
Not sure about that. ISTR a discussion here about a Photodesk speed
comparison SA287 vs. Kinetic 233, and the standard but higher clocked
SA won. It will depend on the specific test case of course.
[snip]
> Which means that, if Castle want to sell *any* Iyonixes to serious graphics
> users, they will *have* to fund the conversion of at least one of the 3 main
> bitmap packages to 32-bit.
I don't see why Castle should fund the conversion, but in principle I agree
that Iyonix needs a fast bitmap graphics package.
> Otherwise it will be an automatic victory to the
> Omega, even without an XScale.
Not so sure about that. It depends on the performance difference between
running it on an Omega, on a StrongARM Risc PC with ViewFinder and an
Iyonix with Aemulor. I think it is also unlikely that "serious graphics
users" only use Photodesk, so it also depends on the speed of other
related software packages.
Steffen
--
steffe...@gmx.de ste...@huber-net.de
GCC for RISC OS - http://www.arcsite.de/hp/gcc/
Private homepage - http://www.huber-net.de/
John Pettigrew
> The current development version of Aemulor is able to emulate ArtWorks at
> around ARM610 speed, this is probably the only thing we know for sure at
> the moment.
True - but, equally, it is surely reasonable to extrapolate tentatively
based on the few data we have?
> > However, we're also told that Omega prototypes run about 2-3 times the
> > speed of an SA RPC
>
> Some applications. Not all. See Aemulor ;-)
Indeed :-)
> > so that is definitely worthwhile - Photodesk should gain somewhat from
> > the ~10-30% faster processor (287 vs 233 MHz SA),
>
> IIRC, Omega is specified with a 300 MHz StrongARM.
Sorry - I realised that wasn't clear after I posted it. I was meaning that
the percentage speed increase would depend on whether you were comparing the
Omega with an SA at 287 or 233 MHz. Or, indeed, 200 MHz.
> > Which means that, if Castle want to sell *any* Iyonixes to serious
> > graphics users, they will *have* to fund the conversion of at least one
> > of the 3 main bitmap packages to 32-bit.
>
> I don't see why Castle should fund the conversion, but in principle I
> agree that Iyonix needs a fast bitmap graphics package.
They wouldn't fund it entirely, of course, but it seems to me that it would
be a sensible investment on Castle's behalf. With something like this, of
course, I would expect it to be an *investment* - Castle would get some
return on 32-bit versions sold. Think of it as an advance...
> > Otherwise it will be an automatic victory to the Omega, even without an
> > XScale.
>
> Not so sure about that. It depends on the performance difference between
> running it on an Omega, on a StrongARM Risc PC with ViewFinder and an
> Iyonix with Aemulor. I think it is also unlikely that "serious graphics
> users" only use Photodesk, so it also depends on the speed of other
> related software packages.
True - but PD is distinctly slow on an SARPC/VF (which is what I use)
because of the podule bus limitations. Of course, we can't tell yet, but I
suspect that the Omega is likely to run PD far faster than an SA RPC/VF
combo, and probably rather faster than Aemulor/Iyonix unless Aemulor gets a
lot faster than is currently reported (which is, of course, quite possible).
And if a 32-bit gfx program comes out, all bets are off again :-)
John
--
John Pettigrew Headstrong Games
john at headstrong-games.co.uk Fun : Strategy : Price
http://www.headstrong-games.co.uk/ Board games that won't break the bank
Fields of Valour: 2 Norse clans battle on one of 3 different boards
Garry
I've no idea what Photodesk are up to, but if you're after a new box
to run Photodesk, maybe you're better off waiting for the Omega, which
is supposed to run 26-bit code at near full speed.
Cheers
Garry
John Kortink
wrote:
>[...]
>
>I've no idea what Photodesk are up to, but if you're after a new box
>to run Photodesk, maybe you're better off waiting for the Omega, which
>is supposed to run 26-bit code at near full speed.
Full speed of what ?
John Kortink
Email : kor...@inter.nl.net
Homepage : http://www.inter.nl.net/users/J.Kortink
ViewFinder, the high performance graphics card for RISC PC's :
visit http://www.windfall.nl for more details and pricing.
John Cartmell
Doctor <thed...@thedeathzone.free-online.co.uk> wrote:
[Snip]
> It gets worse though. APDL seem to be very uninterested in converting
> the software they sell to 32bit. This covers the Pineapple ArtStudio24
> packages which they took over development of sometime ago and now more
> recently the Clares ProArtisan24 which is also covered by APDL since
> they took over the development and distribution of all Clares Micro
> supplies software.
[Snip]
Though presumably not Compo! Rob has been looking at what is needed to
32-bit Composition.
BTW are you sure about ProArt 24? I missed that announcement.
--
John Cartmell jo...@cartmell.demon.co.uk FAX +44 (0)8700-519-527
Acorn Publisher magazine & http://www.acornpublisher.com
Fleur Designs (boardgames)
Peter Naulls
John Pettigrew <jo...@NOT-RELEVANT.headstrong-games.co.uk.INVALID> wrote:
[ 32-bit bitmap packages]
> They wouldn't fund it entirely, of course, but it seems to me that it would
> be a sensible investment on Castle's behalf. With something like this, of
> course, I would expect it to be an *investment* - Castle would get some
> return on 32-bit versions sold. Think of it as an advance...
...you're assuming that all possible bitmap packages are commerical in
nature. They're not. For example, I have a port of The GIMP working
under RiscX.
http://www.chocky.org/unix/downloads/x11/test/
Peter
--
------------------------------------------------------------------------
Peter Naulls - pe...@chocky.org
Homepage - http://www.chocky.org/
RISC OS C Programming - http://www.riscos.info/
Unix Programs on RISC OS - http://www.chocky.org/unix/
------------------------------------------------------------------------
The Doctor
John Cartmell <jo...@cartmell.demon.co.uk> wrote:
> In article <116fc6a64b...@thedeathzone.free-online.co.uk>, The
> Doctor <thed...@thedeathzone.free-online.co.uk> wrote:
>
> [Snip]
>
> > It gets worse though. APDL seem to be very uninterested in converting
> > the software they sell to 32bit. This covers the Pineapple ArtStudio24
> > packages which they took over development of sometime ago and now more
> > recently the Clares ProArtisan24 which is also covered by APDL since
> > they took over the development and distribution of all Clares Micro
> > supplies software.
>
> [Snip]
>
> Though presumably not Compo! Rob has been looking at what is needed to
> 32-bit Composition.
>
True, I forgot about Compo. But then Compo is one of the few (the only?)
Clares products still developed.
> BTW are you sure about ProArt 24? I missed that announcement.
>
I can only go by the announcement on the APDL website. In fact since
ProArtisan24 is probably a direct competitor to Pineapples ArtStudio
(which belongs to APDL now) it wouldn't surprise me if ProArtisan24 is
never heard of again.
The Doctor
James Sargent <ro...@127.0.0.1> wrote:
The impression I got was uninterested at the present time. They are
certainly capable of updating a lot of their software.
The Doctor
John Pettigrew <jo...@NOT-RELEVANT.headstrong-games.co.uk.INVALID> wrote:
> In a previous message, The Doctor wrote:
>
> > In message <dd1ac3a...@xl-cambridge.com>
> > John Pettigrew <jo...@NOT-RELEVANT.headstrong-games.co.uk.INVALID> wrote:
> >
> > > I was told, when I asked that it "worked fine with Aemulot" [sic], which
> > > suggests to me not to hold my breath.
> > >
> > Unfortunately PhotoDesk benefits greatly from as fast a processor as is
> > possible. Running it under emulation would be a definate backwards step.
>
> That's my feeling, too - we're told that Aemulor/Iyonix runs progs at about
> the speed of a RiscPC600, which is a *lot* slower than SA.
>
> However, we're also told that Omega prototypes run about 2-3 times the speed
> of an SA RPC (without any gfx acceleration), so that is definitely
> worthwhile
Only if it is in fact this fast.
I was very unimpressed with the Omega I saw at the M25 user group
demonstration.
> - Photodesk should gain somewhat from the ~10-30% faster processor
> (287 vs 233 MHz SA), but should gain a lot from the *much* faster bus.
> I'd definitely expect it to be a worthwhile upgrade.
>
John Pettigrew
> In message <00a3cfa...@xl-cambridge.com>
> John Pettigrew <jo...@NOT-RELEVANT.headstrong-games.co.uk.INVALID> wrote:
>
> > [ 32-bit bitmap packages]
>
> ..you're assuming that all possible bitmap packages are commerical in
> nature. They're not. For example, I have a port of The GIMP working
> under RiscX.
I'm simply talking about the usable programs that have been publically
released - none of which are 32-bit yet, I don't think. Unless you count
Paint, which (despite all its good qualities) isn't a full bitmap package.
There's been no public release of the GIMP for RISC OS, although I look
forward to it eagerly! In any case, the GIMP has some drawbacks, one of the
most serious of which is that (AFAICT) it works only in RGB mode. If anyone
has worked out how to get it to use CMYK, I'd be grateful to find out how to
do this!
John
--
John Pettigrew Headstrong Games
john at headstrong-games.co.uk Fun : Strategy : Price
http://www.headstrong-games.co.uk/ Board games that won't break the bank
Rob Davison
> In article <116fc6a64b...@thedeathzone.free-online.co.uk>, The
> Doctor <thed...@thedeathzone.free-online.co.uk> wrote:
>
> [Snip]
>
>
>>It gets worse though. APDL seem to be very uninterested in converting
>>the software they sell to 32bit. This covers the Pineapple ArtStudio24
>>packages which they took over development of sometime ago and now more
>>recently the Clares ProArtisan24 which is also covered by APDL since
>>they took over the development and distribution of all Clares Micro
>>supplies software.
>
>
> [Snip]
>
> Though presumably not Compo!
I was aware that there had been changes at Clares but the above is all
news to me! :-(
I'd be a bit put out (to put it mildly) if they were selling it and/or
developing it independently of myself.
> Rob has been looking at what is needed to
> 32-bit Composition.
Indeed.
And I'm about ready to ask if any Iyonix owners out there are willing to
have their email box stretched with a test version? :-)
> BTW are you sure about ProArt 24? I missed that announcement.
IIRC it was pure C so a recompile should be all that is necessary.
Rob.
Peter Naulls
John Pettigrew <jo...@NOT-RELEVANT.headstrong-games.co.uk.INVALID> wrote:
> I'm simply talking about the usable programs that have been publically
> released - none of which are 32-bit yet, I don't think. Unless you count
> Paint, which (despite all its good qualities) isn't a full bitmap package.
But that's an arbitrary point to base your earlier conclusion on. Gimp
works (as far as it goes), and the work to make it a useable RISC OS
application is probably comparable in terms of effort to 32-bitting
PhotoDesk.
> There's been no public release of the GIMP for RISC OS, although I look
> forward to it eagerly!
There has, you've snipped the ealier URL I provided:
http://www.chocky.org/unix/downloads/x11/test/
> In any case, the GIMP has some drawbacks, one of the
Any graphics package will have drawbacks, so it's fortunate we have so
many quality programs on RISC OS.
--
------------------------------------------------------------------------
Peter Naulls - pe...@chocky.org
Homepage - http://www.chocky.org/
RISC OS C Programming - http://www.riscos.info/
Unix Programs on RISC OS - http://www.chocky.org/unix/
------------------------------------------------------------------------
Drobe - http://www.drobe.co.uk/ - Quality, Regular RISC OS News and Views
The Doctor
Rob Davison <rdav...@xxttrraa.ccoo.nnzz> wrote:
> John Cartmell wrote:
> > In article <116fc6a64b...@thedeathzone.free-online.co.uk>, The
> > Doctor <thed...@thedeathzone.free-online.co.uk> wrote:
> >
> > [Snip]
> >
> >
> >>It gets worse though. APDL seem to be very uninterested in converting
> >>the software they sell to 32bit. This covers the Pineapple ArtStudio24
> >>packages which they took over development of sometime ago and now more
> >>recently the Clares ProArtisan24 which is also covered by APDL since
> >>they took over the development and distribution of all Clares Micro
> >>supplies software.
> >
> >
> > [Snip]
> >
> > Though presumably not Compo!
>
> I was aware that there had been changes at Clares but the above is all
> news to me! :-(
>
> I'd be a bit put out (to put it mildly) if they were selling it and/or
> developing it independently of myself.
>
Perhaps I shouldn't have used specific words like development and
distribution, however I now quote directly from their website;
'APDL and proAction have now taken over all of the titles previously
published by Clares Micro Supplies. This includes Schema, Composition,
Rhapsody, and many others. We shall be announcing the new prices for
these products very shortly.'
I didn't mean to make any startling revelations about this.
The statement has been on APDLs website (front page) for a little while
now and I assumed at least some people knew.
VinceH (use reply-to)
The Doctor <thed...@thedeathzone.free-online.co.uk> wrote:
> APDL seem to be very uninterested in converting the software
> they sell to 32bit. This covers the Pineapple ArtStudio24
> packages which they took over development of sometime ago and
> now more recently the Clares ProArtisan24 which is also
> covered by APDL since they took over the development and
> distribution of all Clares Micro supplies software.
Ah...
Which would presumably be why Clares so kindly
chose not to reply to three emails I sent to them
asking about the future (wrt 32bit) of one of
their programs, some time back.
Not even a reply to say "Ask APDL", which was
jolly nice of them.
VinceH
--
VinceH can be found in the vicinity of http://www.vinceh.com
Soft Rock Software can be found around http://www.softrock.co.uk
WebChange2 for RISC OS & Windows is at http://www.webchange.co.uk
John Cartmell
The Doctor <thed...@thedeathzone.free-online.co.uk> wrote:
> I can only go by the announcement on the APDL website. In fact since
> ProArtisan24 is probably a direct competitor to Pineapples ArtStudio
> (which belongs to APDL now) it wouldn't surprise me if ProArtisan24 is
> never heard of again.
As ProArtisan24 is unlike any other art program (or the only art program -
depending upon your definition of art) then I'd be very sorry to see that
happen. I really can't see APDL being so short-sighted.
Gary Locock
<bandits...@yahoo.co.uk> wrote:
> Kell Gatherer <nos...@locsource.com> wrote in message
> news:<4ba6bffb...@locsource.com>...
> > Silence about PhotoDesk: it's not even mentioned at
> > www.iyonix.com, only !OHP from the same company.
> >
> > Today I've had a look at the !PhotoDesk code: The !RunImage file
> > is BASIC, and there is a large module called "Photodesk" in the
> > 'modules' directory. Armalyser declares there is 0.2% of the
> > module code that is not 32-bit neutral. You would have thought,
> > therefore, that !PhotoDesk could be released for Iyonix.
Indeed, if that is so.
> > However, weeks have now gone past without an announcement, which
> > leads me to suspect that there is a problem behind the scenes.
> > Perhaps when Chris 'lost his programmer' he took the source code
> > with him?
> >
> > And now I've heard that Chris Hornby, at the Motorcycle Museum
> > (30th November), when pushed, said "a 32-bit PhotoDesk is
> > unlikely to happen".
> >
> > I use my RPC for lots of different things, the one thing I use it
> > for which is the most processor-intensive is !PhotoDesk, which
> > moves around a lot of data. This is *the* application which would
> > most benefit from being 'ported' to the Iyonix. Also for sure it
> > would be a chargeable upgrade which would benefit PhotoDesk Ltd
> > immensely.
Depending on how many they sell of course
> > Why the silence? Whatever the truth, it is better that we know.
> >
> > ...and if anyone knows better, please put me out of my misery!
> I've no idea what Photodesk are up to, but if you're after a new
> box to run Photodesk, maybe you're better off waiting for the
> Omega, which is supposed to run 26-bit code at near full speed.
I don't see that you need to wait. Yes, Omega will be faster than a
RPC-SA (or there will be a massive queue of people wanting their
money back!) BUT as far as 26-bit apps is concerned, it will be the
final end of the road.
Iyonix could be /quickly/ adapted by Castle to accept newer faster
versions of the X-Scale when they come out, as they surely will.
To be sure, Omega can have daughter boards too, but like Iyonix,
they can only be 32-bit. The famous FPGAs, as well as keeping
the price high, will have a speed ceiling too, no doubt. And
AIUI, the launch machines won't even have the daughter boards
fitted. (How many months away are those, I wonder?).
Any new X-Scale daughterboards for Omega, will obviously benefit
32-bit apps. If Photodesk does /not/ get 32-bitted, the Omega
is stuck with the speed of the upclocked SA soldered to its
m/b. And 300MHz or so sounds pretty pedestrian for 2003.
When your new Omega is two years old, that speed will sound
positively arthritic.
So, Omega will offer an immediate speed boost to Photodesk, but that
is your lot! Nothing more coming, unless/until Photodesk goes 32-bit.
OTOH, a future Iyonix with (say) double the current processor speed,
will also double the speed of 26-bit Photodesk under Aemulor. There
is no limit to future speed-ups, on Iyonix-type derivatives; its just
that Photodesk will not seem fast in comparison to 32-bit software
running /on that machine at that time/.
The killer, I suspect, is that Iyonix is a much less complex
machine than Omega, so it will always be possible to sell it
it cheaper/more profitably. Omega is looking very
expensive lately; it isn't going to open up a vast new user
base at that price; and the 26-bit speed-up on offer looks
pretty puny, 2 years down the line from when it was first
put forward. PC speeds have more than doubled in that time.
So, ISTM that the logic is firmly on the side of the Iyonix for
Photodesk users in the long run. The best way for there to /be/ a
long run, is obviously to get Photodesk converted. The second best
way is to support the Aemulor developers /now/, so that Photodesk can
look forward to incremental speed-ups from new generations of 32-bit
ARMs. 32-bit or 26-bit; the Castle strategy is the one that offers
future accelerations for both eventualities, AFAICS.
I'm afraid, people, that 26-bit processors have no future. There
is no choice in the matter. We either move forward, or settle into
some kind of technological museum. I'm surprised that APDL,
Photodesk, and others mentioned in this thread, not to mention
ROL themselves, don't seem to want to believe that.
--
Gary Locock, Network Manager, Bablake Junior School
Coundon Road, Coventry CV1 4AU
School Website: http://www.bablakejs.co.uk
Garry
> On 18 Dec 2002 07:21:08 -0800, bandits...@yahoo.co.uk (Garry)
> wrote:
>
> >[...]
> >
> >I've no idea what Photodesk are up to, but if you're after a new box
> >to run Photodesk, maybe you're better off waiting for the Omega, which
> >is supposed to run 26-bit code at near full speed.
>
> Full speed of what ?
>
>
> John Kortink
An Omega, but I've no idea how fast that actually is, but I expect
it'll be faster than an Iyonix running the emulator.
Garry
Martin Wuerthner
John Pettigrew <jo...@NOT-RELEVANT.headstrong-games.co.uk.INVALID> wrote:
> In a previous message, The Doctor wrote:
>
> > In message <dd1ac3a...@xl-cambridge.com>
> > John Pettigrew <jo...@NOT-RELEVANT.headstrong-games.co.uk.INVALID> wrote:
> >
> > > I was told, when I asked that it "worked fine with Aemulot" [sic], which
> > > suggests to me not to hold my breath.
> > >
> > Unfortunately PhotoDesk benefits greatly from as fast a processor as is
> > possible. Running it under emulation would be a definate backwards step.
>
> That's my feeling, too - we're told that Aemulor/Iyonix runs progs at about
> the speed of a RiscPC600, which is a *lot* slower than SA.
>
> However, we're also told that Omega prototypes run about 2-3 times the speed
> of an SA RPC (without any gfx acceleration), so that is definitely
> worthwhile
Maybe I misunderstood: Do you mean "Omega prototypes run PHOTODESK about
2-3 times the speed of an SA RPC?", then I cannot comment on that. If you
mean the computer itself runs at that speed, then I doubt it very much. Do
not forget: Fast memory is good, but it can not magically speed up your
computer. It can only AVOID slow-downs, it can never speed up a processor
beyond its maximum speed.
If you want to have a rough estimate on the upper bound of the speed of an
SA Omega for tasks not involving disc access, simply take the speed of a
Kinetic RiscPC and multiply it by the ratio of the processor clock
frequencies. That is it. No significant magical speed-up possible beyond
this point.
> Which means that, if Castle want to sell *any* Iyonixes to serious
> graphics users, they will *have* to fund the conversion of at least one
> of the 3 main bitmap packages to 32-bit. Otherwise it will be an
> automatic victory to the Omega, even without an XScale.
Personally, I am pretty confident that a Iyonix version of PhotoDesk will
be available sooner or later.
Martin
--
---------------------------------------------------------------------
Martin Wuerthner MW Software mar...@invalidMW-software.com
remove "invalid" to reply
---------------------------------------------------------------------
Malcolm Ripley
"Gary Locock" <ga...@locock.demon.co.uk> wrote in message
news:4ba70c7...@locock.demon.co.uk...
ARMTwister again. The ARMTwister converts 26-bit code to 32-bit code
in real time. That 32-bit code is run on whatever processer is in the
machine. By default there is a soldered StrongARM in which will run
the 32 bit (26-bit translated) code on it. If a daughter card is
inserted then the 32-bit (26 bit translated) code will run on that.
It is for this reason that MD stated that code switching was no longer
necessary (and in effect neither is the StrongARM anymore but I would
strongly suspect removing it completely involves a unwelcome
motherboard change).
Therefore, Photodesk will run at near full StrongARM speed on a
StrongARM only Omega. It will run at near full X-Scale speed on
an Omega fitted with a X-Scale daughter card.
Of course this assumes that ARMTwister works as well as they have
stated it does.
regards,
Malcolm
Wilfred
Rob Davison <rdav...@xxttrraa.ccoo.nnzz> wrote:
> And I'm about ready to ask if any Iyonix owners out there are willing to
> have their email box stretched with a test version? :-)
Yes Please!!!!
Wilf
> > BTW are you sure about ProArt 24? I missed that announcement.
> IIRC it was pure C so a recompile should be all that is necessary.
> Rob.
--
Wilf Beeson - wilfred...@btinternet.com
Lichfield Diocese and Walsall Deanery Webmaster
http://www.lichfield.anglican.org/
Http://www.lichfield.anglican.org/walsall/walsall/
Produced using a Strongarm RiscPC (Windows Outside)
Garry
Forgot to put 'Omega with Xscale daughterboard' in the above, but
anyway I'm sure an Omega owner will be able to tell us how fast it
goes now that they have apparently shipped.
Cheers
Garry
ag.
Kell Gatherer <nos...@locsource.com> wrote:
> I was at the ROUGOL meeting on Monday night where Jack Lillingston
> presented Iyonix. PhotoDesk was mentioned, and various comments were
> made, including (from the crowd): "I heard that it can't be done now
> that Chris lost his programmer."
that wasn't the only shock it appears that key names were about to leave
the Risc OS market before they were persuaded to stay for iyonix
now the question is stay for what and for how long?
ag
druck
> Maybe I misunderstood: Do you mean "Omega prototypes run PHOTODESK about
> 2-3 times the speed of an SA RPC?", then I cannot comment on that. If you
> mean the computer itself runs at that speed, then I doubt it very much. Do
> not forget: Fast memory is good, but it can not magically speed up your
> computer. It can only AVOID slow-downs, it can never speed up a processor
> beyond its maximum speed.
But most of Photodesks functions are entirely memory bound on a StrongARM.
> If you want to have a rough estimate on the upper bound of the speed of an
> SA Omega for tasks not involving disc access, simply take the speed of a
> Kinetic RiscPC and multiply it by the ratio of the processor clock
> frequencies. That is it. No significant magical speed-up possible beyond
> this point.
It is one of the few applications that shows a full 2.5x speed increase
when using a Kinetic card. So I strongly beleive that however much faster
the Omega's memory is, that is how much faster many of the image operations
will run at.
>> Which means that, if Castle want to sell *any* Iyonixes to serious
>> graphics users, they will *have* to fund the conversion of at least one of
>> the 3 main bitmap packages to 32-bit. Otherwise it will be an automatic
>> victory to the Omega, even without an XScale.
>
> Personally, I am pretty confident that a Iyonix version of PhotoDesk will
> be available sooner or later.
Agreed.
---druck
--
The ARM Club * http://www.armclub.org.uk/
Gary Locock
<mri...@argonet.co.uk> wrote:
> "Gary Locock" <ga...@locock.demon.co.uk> wrote in message
> news:4ba70c7...@locock.demon.co.uk...
> > In article <b5652016.0212...@posting.google.com>,
> > Garry <bandits...@yahoo.co.uk> wrote:
> > > Kell Gatherer <nos...@locsource.com> wrote in message
> > > news:<4ba6bffb...@locsource.com>...
> > > > Silence about PhotoDesk: it's not even mentioned at
> > > > www.iyonix.com, only !OHP from the same company.
> > > >
<SNIP>
> > > > Why the silence? Whatever the truth, it is better that we
> > > > know.
> > > >
> > > > ...and if anyone knows better, please put me out of my misery!
> >
> > > I've no idea what Photodesk are up to, but if you're after a
> > > new box to run Photodesk, maybe you're better off waiting for
> > > the Omega, which is supposed to run 26-bit code at near full
> > > speed.
> >
> > I don't see that you need to wait. Yes, Omega will be faster
> > than a RPC-SA (or there will be a massive queue of people wanting
> > their money back!) BUT as far as 26-bit apps is concerned, it
> > will be the final end of the road.
<SNIP>
> Wrong. I think you need to read the Microdigital description of
> ARMTwister again. The ARMTwister converts 26-bit code to 32-bit
> code in real time. That 32-bit code is run on whatever processer
> is in the machine. By default there is a soldered StrongARM in
> which will run the 32 bit (26-bit translated) code on it.
(Why would it need to translate code for the SA??)
> If a daughter card is inserted then the 32-bit (26 bit translated)
> code will run on that. It is for this reason that MD stated that
> code switching was no longer necessary (and in effect neither is
> the StrongARM anymore but I would strongly suspect removing it
> completely involves a unwelcome motherboard change).
IU that the XScale option will not be fitted to the initial machines,
in which case removing the SA would have even more unwelcome
consequences ;-)
Release (of the SA version?) is now said to be due in January (2003):
so people will /still/ be "waiting" to see if ARMTwister works at
all, and how fast.
> Therefore, Photodesk will run at near full StrongARM speed on a
> StrongARM only Omega. It will run at near full X-Scale speed on an
> Omega fitted with a X-Scale daughter card.
"Near full X-Scale speed". =We don't know /how/ near, but we do
know it will be less (obviously).
Even now, nobody outside MD appears to have tested this machine in
earnest. At this stage in the Iyonix launch process (assumimg the
January 2003 release actually happens) lots of developers were known
(despite NDAs) to be testing pre-release machines.
Make no mistake; I have an evaluation Omega on order; I very much
hope it does all it claims. It will be nicer still if all the
32-bittery works as well, because in education we have a
serious issue with legacy software that will never be converted.
It is this "Better off waiting" idea that I am challenging. The wait
has been long enough already. People have been waiting for so long
now, it has become a way of life!
There is a fast machine available at the moment; it is real, it
exists, it works. There is one sitting on my desk. It will be able
to run Photodesk.
When the unavailable machine reaches the market, it will contain a
6-year old (? - I think) CPU and slower memory than the Iyonix. In
the short term, the souped-up SA may well run Photodesk quicker, but
it is bound to run fully 32-bit apps slower than Iyonix can.
There will then be a further wait until anyone finds out for sure
whether the ARMtwister/XScale device works in practice. How long?
Nobody knows. How fast? Nobody knows. We do know that the XScale
option will make it significantly more expensive than the Iyonix.
A bird in the hand, or two in the bush? Are there really two birds
in the bush anyway? Realistically, we do not know. That is why I
think waiting even longer to find out makes no sense at all... unless
you just happen to like waiting!
Better by far, IMO, to make sure that the fast machine that /does/
exist, becomes a great success, and thus gets lots more software
converted to run on it. Including Photodesk.
> Of course this assumes that ARMTwister works as well as they have
> stated it does.
Quite.
Hedley Hunnisett
> Not even a reply to say "Ask APDL", which was
> jolly nice of them.
software. No reply. I'll try again, it may be a case of 3rd time lucky!
:-)
--
Hedley Hunnisett of Wigston Magna, Leicestershire.
Using British RISC technology with StrongARM power!
VinceH (use reply-to)
Steven Pampling <steve.p...@argonet.co.uk> wrote:
> In article <4ba6f5ff...@softrock.co.uk>, VinceH (use
> reply-to) <spa...@softrock.co.uk> wrote:
> > Which would presumably be why Clares so kindly chose not to
> > reply to three emails I sent to them asking about the future
> > (wrt 32bit) of one of their programs, some time back.
> WimpBasic I presume.
Indeed.
As I'm sure most people realise, the front end for
WebChange is written with WB[1] - so the future of
that affects the future of WebChange and/or the
amount of work I have to fit into the lack of time
available to me in which to fit it; the lack of any
reply from Clares has meant that I've started down
the path of hardest work.
[1] With the back end in C.
Which, essentially, is writing a new front end, from
scratch, in C. I know a number of people probably
think I should have done that in the first place
anyway, but I didn't - the reason being quite simply
that I've only ever programmed very rudimentary WIMP
stuff in Basic, so something as complicated as I
(correctly) expected WebChange to become would have
meant a large amount of work coupled with a large
learning curve.
And now I face that very same learning curve and
amount of work anyway, so it was a false economy
- all I can say to that is "ho hum." (And it may be
/less/ of a learning curve now than it would have
been way back when in any case, because I'm sure
WimpBasic will have lessened it somewhat - but that
does remain to be seen).
I don't think I'll bother asking APDL their plans -
for the moment, I'll take a Magnus Magnusson
approach, and carry on what I've started. In the
long run it's probably for the best anyway. It might
take a long time, with the stupid amount of work I'm
up to my neck in[2], but that's life and (RISC OS)
software development for you. If they announce
something suitable about WimBasic in the mean time,
I *might* change my mind - it probably depends how
much I've done by the time an announcement is made
as well as, obviously, what the announcement says.
We'll see.
(In an ideal world, I'll be demonstrating the 32bit
version of WebChange at the SW show in February -
but I can't say that for certain at this stage.)
[2] Every time I mention the amount of work I have
on groups such as this, I end up with an
increased amount shortly after, so I probably
shouldn't have said that. Maybe this comment
will negate the effect. :-)
(OTOH, it's good for cash flow - I want more
dosh in the bank? Just say on csa that I'm
doing too much work... )
> > Not even a reply to say "Ask APDL", which was jolly nice of
> > them.
> The APDL message in csa.announce seemed a bit short too.
Well it concentrated on only one app, and said
further announcements were to come for others,
which was fair enough. It's just a shame this
first announcement was about the *wrong* item. :-)
> Maybe they've had a number of queries already.
Possibly - but when was that little news item
about APDL taking over Clares products first added
to the website (why don't they use WebChange? ;-)
The first I knew about it was when I read Graham's
post above - to be followed shortly after by the
announcement in csaa; so I suspect it was only
*very* recently put up - which would suggest to me
that they can't have had many queries, unless (say)
people were querying Clares prior to this becoming
public knowledge, and Clares were saying "Ask APDL"
in precisely the exact same way that they didn't
say that to me. (Which was jolly nice of them).
Andrew Flegg
>
> As I'm sure most people realise, the front end for
> WebChange is written with WB[1] - so the future of
> that affects the future of WebChange
Have you looked at WimpWorks? We've got a 32-bit compatible demo version
available now, and would be happy to help you migrate WebChange to use
WimpWorks instead of WB. Other advantages would include not having to
distribute support modules with your application: it's totally stand
alone with WimpWorks.
Cheers,
Andrew
--
Andrew Flegg -- mailto:and...@jaffasoft.co.uk | What's stopping you creating
-- http://www.jaffasoft.co.uk/ | Desktop applications?
-- phone: +44 (0)7010 704228 | Time? Money? Nothing.
\--> WimpWorks - only 39.99ukp
druck
> In article <4ba6f5ff...@softrock.co.uk> use reply-to wrote:
>
> > Not even a reply to say "Ask APDL", which was
> > jolly nice of them.
>
> Mind you, I've emailed APDL twice recently with a query about updating
> software. No reply. I'll try again, it may be a case of 3rd time lucky!
Dave Holden prefers the phone. I've never managed to have a phone enquiry
answred with less than 4x as much helpful information as was strickly
necessary!
VinceH (use reply-to)
Andrew Flegg <and...@jaffasoft.co.uk> wrote:
> In article <4ba7b996...@softrock.co.uk>, VinceH (use
> reply-to) wrote:
> > As I'm sure most people realise, the front end for
> > WebChange is written with WB[1] - so the future of
> > that affects the future of WebChange
> [snip]
> Have you looked at WimpWorks? We've got a 32-bit compatible
> demo version available now, and would be happy to help you
> migrate WebChange to use WimpWorks instead of WB. Other
> advantages would include not having to distribute support
> modules with your application: it's totally stand alone with
> WimpWorks.
It's a possibility, of course, but there are more
issues than 32bittiness.
The first and most significant one is that it's so
long since I've written a program in [ordinary]
BASIC that I'm not sure if I can go back to it.
It's just so limiting! :-) (AIUI WimpWorks means
using good old BBC BASIC with extensions as
provided by WW - or am I think of someting else
entirely? You are, of course, in the perfect
position to tell me I'm so wrong about that that
I've created a whole new definition of the word.)
Then there's code readability. Experience has told
me that having code which is both readable and
alterable by the end user leads to situations
whereby the user changes something, forgets that
they've done so (or what they've done) and either
loses what they've done in an upgrade and thus
declares the upgrade broken, or asks for support
and - not surprisingly - I can't reproduce the
problem here, so I end up searching for a bug
which isn't in any version of the software I've
released. This sort of nonsense happened on
several occasions with programs like Trellis and
a few freebies I released over the years.
I won't release anything in (clear) BASIC again.
Ever.
Having the 32bit tools as supplied by Castle
obviously means I now have the ABC compiler - so
it might be possible to tempt/persuade me to
experiment if code written with WW can then be
compiled with that. Is that possible?
(But in truth, I'm more likely to take the C
route as planned - not least because I've already
started down that route!)
Andrew Flegg
>
[WimpWorks for WebChange]
>
> It's a possibility, of course, but there are more
> issues than 32bittiness.
Ahh.
> The first and most significant one is that it's so
> long since I've written a program in [ordinary]
> BASIC that I'm not sure if I can go back to it.
> It's just so limiting! :-)
Is this compared with WimpBASIC or something above and beyond (eg.
Visual Basic)
> (AIUI WimpWorks means using good old BBC BASIC with extensions as
> provided by WW - or am I think of someting else entirely?
You're right - WimpWorks is standard BBC BASIC with additional commands
added. These are translated when you save your application into fully
legal "normal" BBC BASIC. It's then packaged together with the necessary
bits of WimpWorks to make it run and spat out as !App.!RunImage - as an
absolute file.
[snip reasons about modifiable code]
>
> I won't release anything in (clear) BASIC again.
> Ever.
That wouldn't be an issue with WimpWorks. There's no clear BASIC code
accessible to the end-user and if you remove the !App.WWv2Data file then
your application won't be editable in WimpWorks either. (Of course, one
would normally have a backup which *is* editable ;-))
> Having the 32bit tools as supplied by Castle
> obviously means I now have the ABC compiler - so
> it might be possible to tempt/persuade me to
> experiment if code written with WW can then be
> compiled with that. Is that possible?
Not at the moment. The !RunImage of applications produced using
WimpWorks are Absolute files, but it's still interpreted BASIC behind
the scenes. With the speed of modern machines, the advantages to be had
by compiling BASIC seem to be slim; and the disadvantages (lack of EVAL,
and do you still lose inline assembler?) are rather great.
If speed is essential then WimpWorks can use BasCompress to crunch your
code but at the moment that's the only external code optimiser/compiler
supported.
> (But in truth, I'm more likely to take the C
> route as planned - not least because I've already
> started down that route!)
Ahh, now *that*'s a good reason ;-)
VinceH (use reply-to)
Andrew Flegg <and...@jaffasoft.co.uk> wrote:
> In article <4ba7ec81...@softrock.co.uk>, VinceH (use
> reply-to) wrote:
> > The first and most significant one is that it's so
> > long since I've written a program in [ordinary]
> > BASIC that I'm not sure if I can go back to it.
> > It's just so limiting! :-)
> Is this compared with WimpBASIC
I was thinking of BBC BASIC - WimpBasic, while still
BASIC, seems to me to be sufficiently different that
I don't think of it in the same way.
Although, obviously, it is a version of /BASIC/ and,
as such, means I've happily coded in that language
that some might see my comments above as just a bit
nonsensical; but ATEOTD, *I* know what I'm talking
about so that's all that matters.
> or something above and beyond (eg. Visual Basic)
VB is a different kettle of fish and, based on the
version I've used, I don't think it should have
been labelled as a version of BASIC.
An interesting point with VB is that when I wrote
the VB version of WebChange, I found it
*incredibly* easy to take the back-end C programs
from the RISC OS version use them as a basis for the
equivalent code in VB. (So there really was no
excuse for not updating that version in line with
the RISC OS version, other than just not liking the
environment - but that has no relevance to this
discussion! :-)
<aside>
I'm probably going to make the full Windows version
freely available in the near future, since it's so
out of date and lacking in features c/w the RISC OS
version. It's actually quite shocking to look at the
Windows version and think that the RISC OS version
was once no better than that... it's come a long way
since!
</>
> > (AIUI WimpWorks means using good old BBC BASIC with
> > extensions as provided by WW - or am I think of someting
> > else entirely?
> You're right - WimpWorks is standard BBC BASIC with additional
> commands added. These are translated when you save your
> application into fully legal "normal" BBC BASIC. It's then
> packaged together with the necessary bits of WimpWorks to make
> it run and spat out as !App.!RunImage - as an absolute file.
I see...
> [snip reasons about modifiable code]
> > I won't release anything in (clear) BASIC again.
> > Ever.
> That wouldn't be an issue with WimpWorks. There's no clear
> BASIC code accessible to the end-user and if you remove the
> !App.WWv2Data file then your application won't be editable in
> WimpWorks either.
Is the WWv2Data specific to the app that has been
written, or a standard file?
ie, if I were to use WimpWorks, and remove that file
in the release version - could somone who has
WimpWorks simply put that file in place as taken
from another app, and thus see/edit/bugger up the
code?
If not, then the problem of user visible/editable/
bugger-up-able code is *not* a problem, so that's a
point in WimpWorks' favour.
> (Of course, one would normally have a backup
> which *is* editable ;-))
Of course! :-)
I've never ever ever lost any source code to any
programs at all, ever, oh no.
(Shut up about CNewsMerge, Reg ;-)
(Don't say a word about Floopy, Dave ;-)
> > Having the 32bit tools as supplied by Castle
> > obviously means I now have the ABC compiler - so
> > it might be possible to tempt/persuade me to
> > experiment if code written with WW can then be
> > compiled with that. Is that possible?
> Not at the moment. The !RunImage of applications produced
> using WimpWorks are Absolute files, but it's still interpreted
> BASIC behind the scenes. With the speed of modern machines,
> the advantages to be had by compiling BASIC seem to be slim;
> and the disadvantages (lack of EVAL,
Yes... EVAL is rather important to another of my
ageing programs: Trellis. Many moons ago I bought
RiscBasic, without knowing or realising about the
EVAL limitation, IIRC specifically for that. :-/
> and do you still lose inline assembler?) are rather great.
I vaguely recall reading something recently
suggesting inline assembler *is* possible with ABC,
but I could very easily be mis-remembering.
I don't use any anyway. My ARM is far too rusty -
not that I was ever all that good with it anyway.
> If speed is essential then WimpWorks can use BasCompress to
> crunch your code but at the moment that's the only external
> code optimiser/compiler supported.
Speed isn't an issue in the front end. Anything
speed critical is put in the back end, which is all
in C.
The downside of this, though, is that all these
back-end programs are run as separate apps, although
they simply run, do a job, then quit - but in some
cases, they'll run another. At worse, IIRC, there
could be three of the back-end programs running at
640K each, along with (obviously) the front end; so
memory can be tight on a low memory machine.
This would be another good reason for writing a
new front end in C - once such a front end is
stabilised, I could start integrating the back-end
code, and ultimately have just a single executable
for the main bulk of the program.
The more I think about it, the more I think I should
have done this years ago... :-)
(Cue a chorus of "We told you so")
> > (But in truth, I'm more likely to take the C
> > route as planned - not least because I've already
> > started down that route!)
> Ahh, now *that*'s a good reason ;-)
Indeed.
It doesn't stop me investigating WimpWorks, though.
It might just prove to be a handy addition to my
arsenal.
Brian D
[snip]
> Is the WWv2Data specific to the app that has been
> written, or a standard file?
>
> ie, if I were to use WimpWorks, and remove that file
> in the release version - could somone who has
> WimpWorks simply put that file in place as taken
> from another app, and thus see/edit/bugger up the
> code?
>
> If not, then the problem of user visible/editable/
> bugger-up-able code is *not* a problem, so that's a
> point in WimpWorks' favour.
>
I've just checked a program I wrote with WW2 to control my modem. If you
remove the data file you can no longer edit it, but it still runs ok. I just
wish I had a few more REMs in it, I needed to alter it recently 8-(.
--
Brian D | RiscPC600 | StrongARM 233Mhz RISC OS 4 66Mb
Linux PCs on RISC OS network |
Darlington Dolphin Masters ASC | <www.darlington-masters.org>
Kevin Wells
"VinceH (use reply-to)" <spa...@softrock.co.uk> wrote:
[snip]
The way I learned ti program is by monkey see monkey do.
That means (clear basic) and if someone alters a programe thats their
problem if it does not work.
Kev Wells http://kevsoft.topcities.com
Swinging Arm and Touring Motorcycle Club http://saat.topcities.com
Of Motorway Fuel Prices http://www.mway.0catch.com
More flick able than a bogie during double maths
Andrew Flegg
> In article <slrnb06v9c...@kay.intranet.bleb.org>,
> Andrew Flegg <and...@jaffasoft.co.uk> wrote:
>
>> There's no clear BASIC code accessible to the end-user and if you
>> remove the !App.WWv2Data file then your application won't be
>> editable in WimpWorks either.
>
> Is the WWv2Data specific to the app that has been
> written, or a standard file?
Yes, the WWv2Data file contains all the code, menu definitions etc. of
your application. The only bit of your application that *isn't* stored
in WWv2Data are the !Sprites, Messages and Templates - ie. all the stuff
that can be used directly. All the stuff which makes the application the
application is in WWv2Data so, if deleted, WimpWorks is unable to
reconstruct the application (hell, WimpWorks wouldn't even know the app
was produced with WimpWorks)
> ie, if I were to use WimpWorks, and remove that file
> in the release version - could somone who has
> WimpWorks simply put that file in place as taken
> from another app, and thus see/edit/bugger up the
> code?
No. In fact, the main !WimpWorks application with all the editors etc.
is written in WimpWorks - but has no WWv2Data file.
> If not, then the problem of user visible/editable/
> bugger-up-able code is *not* a problem, so that's a
> point in WimpWorks' favour.
:-)
> I've never ever ever lost any source code to any
> programs at all, ever, oh no.
Me neither ;-)
> I vaguely recall reading something recently
> suggesting inline assembler *is* possible with ABC,
> but I could very easily be mis-remembering.
I thought that too, but couldn't remember where.
> This would be another good reason for writing a
> new front end in C - once such a front end is
> stabilised, I could start integrating the back-end
> code, and ultimately have just a single executable
> for the main bulk of the program.
Makes sense.
> It doesn't stop me investigating WimpWorks, though.
> It might just prove to be a handy addition to my
> arsenal.
Well, I'd think so - but then I'm biased ;-)
VinceH (use reply-to)
Kevin Wells <kev....@dsl.pipex.com> wrote:
> In message <4ba7ec81...@softrock.co.uk> "VinceH (use
> reply-to)" <spa...@softrock.co.uk> wrote:
[...]
> > Then there's code readability. Experience has told
> > me that having code which is both readable and
> > alterable by the end user leads to
[...user-inserted bugs]
> > I won't release anything in (clear) BASIC again.
> [snip]
> The way I learned ti program is by monkey see monkey do.
Yes, many people have over the years - although I
personally think that this is really only
appropriate when the software has been written and
published with that in mind.
If you try to learn by looking at code which was
written to do whatever job is intended for the
final application, you'll wind up picking up bad
habits where the programmer had bad habits, and
believing that what are in reality nasty tricks to
achieve something not otherwise easy (or quick)
are actually the proper way to do something.
> That means (clear basic) and if someone alters a programe
> thats their problem if it does not work.
That's a nice idea in theory[1] - but it's what
actually happens that's important. The problem
comes when such a user reports it as a bug, and
fails to mention (or even remember) that they've
made such a change. If I don't know that they've
done something to break it, then it becomes very
much *my* problem, because the problem is AFAIK
in my code - even though I'm unable to find and
fix it.
I know this is true because it has happened with
my software on more than one occasion - as I
said.