To: stik@ON-Luebeck.DE
Subject: Re: [3] STIK: STiK 2.x concerns                                                 


On Sat, 22 Feb 1997 01:13:57 Martin Mitchell <mem@mode wrote: 
>
>On Thu, 20 Feb 1997, Ronald Andersson wrote:
>
----- snip ----- re: $15 registration fee for Pinhead
>
>It is certainly too much, and it has already cost me enough time and money
>with its failings in the past.
>
That is up to you.


----- snip ------ re: Pinhead (bugfix or not?)
>
>So any program which operates slowly has bugs? This is indeed a strange
>definition of a bug.

When the slowness approaches uselessness I do regard it so.


----- snip ----- re: Tos 1.0 Pexec VS improved Pexec of Pinhead
>
>They are inefficient, but not faulty - they do work, they are just a
>little slower.

No, they are a *lot* slower, especially with extended RAM.


----- snip ----- re: more on bugfix/not_bugfix status of Pinhead
>
>I have the original developer materials for TOS 1.00. Nowhere does it make
>mention of the fastload bit, so at the time, this was correct behaviour.

Of course it wasnt mentioned, but the program loading was ridiculously slow
on all machines (except those old 260ST models).  The fastload bit would
never have been needed unless Atari had insisted on keeping the original
'slowload' method so long that applications appeared which depended on it.
The 'bug' I speak of is not the lack of a 'fastload' bit implementation,
but the very existence of the 'slowload' method.

What Atari at that time considered 'correct' or not, is of very little
interest to a user wanting his machine to operate at decent speed.


>> >do it yourself. I'm trying to free STiK from such personal assumptions.
>> 
>> I suggest that without PINHEAD using TOS 1.0 is such a pain that people
>> will not endure it anyway.  That is my honest opinion.  I'm sorry you had
>> those problems with early PINHEAD versions, but I don't see why this need
>> affect your attitude to later improved versions.
>
>You suggest that, but have you tried it personally?

Oh yes, for several years.  Even long after I got TOS 2.06 I had the old 1.0
accessible by switching, so I could test compatibility of various programs.
I no longer have the ST I used for this though, having given it to a friend
when his system broke down.  Today I test on a Falcon with TOS 4.04 and on a
Mega ST with TOS 2.06 (with WINX 2.3g) and unmodified TOS 1.04 (switched).

I would have to set up another machine for testing TOS 1.0 again, or extend
the Mega ST EPROMS using a 'larger' type (27c040).  At present I have no real
inclination to do either, though I may do the former as I begin to experiment
with larger local networks for STiK 2.


>I really don't think you can express a valid view on this point until you have
>tried it yourself.

Which I have.


>My distrust of Pinhead is due to the data loss I experienced as a result of
>its use. I have no confidence in the reliability of that program anymore, and
>will certainly not register it.

That is your decision, to make for yourself.  I must add though that it does
not match any opinion on Pinhead that I have met before.

I belive that your data loss may very well have been due to other problems with
TOS 1.0, needing other bugfix patches that you seem to be unaware of.  The first
TOS from Atari capable of handling harddisk with any degree of security without
having been patched was TOS 1.02, not TOS 1.00.  Even that had many serios bugs
in its disk routines, though most of these led to inefficiency rather than harm.


----- snip ----- re: marginalization of the issue
>
>I accept you have tried to present relevant points, but I don't think you
>can fully appreciate the issues here unless you have the opportunity to
>try it yourself.

Which I have, as stated above.


----- snip ----- re: Martin's new suggestions for a module format & loader
>
>Well, I mentioned the format in the sentence above. To elaborate a little:
>each module is stored on disk with the standard $1C length program
>header which all programs use.

Yes I definitely agree on this, since it is an absolute requirement for many
compiled languages.  (regardless of variable start-up modules)


>At the start of the Text segment, there is a branch instruction which points
>to a rts instruction.  Hence if the module is accidentally run as a standard
>program, it will just exit harmlessly.

Actually any code should be acceptable that leads to some form of harmless
non-residence. Your suggestion gives me a bus error though, which I dislike.
That does not invalidate the principle of course, though I suggest some other
code be used to avoid bombs.


>After the branch instruction, there is a structure for the module header,
>including module name, version, and pointers to essential module functions,
>such as ones to install/remove itself, ones to initialise itself and so on.

The advantages of having such a header are quite obvious to me too, but I do
not agree that it must necessarily begin at a precise offset from module start.

That limits implementation to those languages allowing the initial entry code
to be modified.  It would be better (I think) to have a specific magic string
in the header, allowing it to be found at other offsets too, or possibly use
the program entry as a function returning a pointer to the structure.

Safe recognition of abnormal program start-up could be implemented simply by
having other magic values and test for their existence as function arguments.

This scheme would allow more languages to be used, since those that do not have
static pointer array initialization (eg: GFA Basic) could then use that entry
function to patch the pointers needed in the structure before returning the
address of it to STiK.

I should add again that my own favourite language is assembler, where these
things are no problem at all, and which will allow more efficient optimization.
Even so, I do not think we should unnecessarily limit STiK programming to those
who share our taste in languages, whatever that may be (C, Asm, or whatever.).

Finally, none of the above (except entry rts) is bound to any specific loader
scheme, but can be equally well implemented in either of the schemes discussed.


>I feel (and have felt) disinclined to spend any more time expanding on
>this at the moment, because I have not been encouraged by the recent mails
>on the list that any input of this kind to the project is welcomed.

I think you have misunderstood the attitude of some of us then (it happens).
Both I and Nick have repeatedly urged all involved to start settling these
issues so we can get on with things, and I'm sure others are interested too.
Not all perhaps, but that seldom happens on technical subjects anyway.


>If you have any further specific questions, please ask them.

Well, I brought up some things above, which I naturally want your response to.
Additionally, you have sometimes mentioned problems in the actual interface
which I would also like to hear your views on.  Without knowing more about
the changes you'd like it is hard for me to be more specific.

-------------------------------------------------------------------------
Regards:  Ronald Andersson                     mailto:dlanor@oden.se
                                               http://www.oden.se/~dlanor
-------------------------------------------------------------------------
