To: perot@pallas.amp.uni-hannover.de
Subject: Re: [3] Another success : UDP                                                   


On Fri, 24 Jan 1997 23:43:55 Peter Rottengatter <perot wrote: 
>
>On Fri, 24 Jan 1997, Ronald Andersson wrote:
>
>I run my second ST for the testing from floppy too. You do not need a 
>harddrive for this.

I didn't think so, but floppy use is so slooooow.
Even so I will probably do it that way anyhow.
The older harddrive I though of using sucks up a lot of power, and tends to
overload the PSU I use for the ST as well as my CD-ROM.  (An old apple 2 PSU)


>> I guess I'll have to modify the routing anyway, so please specify how.
>
>Assign two IP addresses, say 192.68.0.1 for your Falcon's port, and 
>192.68.0.2. for your ST's port. Thus enter 192.68.0.1 into the STiK Port 
>Setup on the Falcon, and 192.68.0.2 on the ST. Use 255.255.255.0 as net 
>mask in both cases, and, say, 1500 as MTU. You can use the same routing 
>table for both machines, if you only write one line
>

The subnet mask below is not what you specified for the table in your file
ESTABLIS.TXT which used 0.0.0.0 instead.  Could that be it ?  (I'll try)
                ||| ||| ||| |
                ||| ||| ||| |
>0.0.0.0        255.255.255.0        Midi      0.0.0.0
>        ^^^^^^               ^^^^^^      ^^^^
>        Use TABs here.
>
>into the file. Click 'Reload Routing' and 'Active' to be selected, and 
>click OK. If you've clicked STiK active in STiK Internals, then you're 
>connected now. Now start ping on your Falcon, and try
>
>a) 127.0.0.1        Packets are echoed by the Falcon's IP
>b) 192.68.0.1       Packets still stay inside the Falcon
>c) 192.68.0.2       Packets now go to the ST and are echoed there.
>
>
>> >If nothing of all this helps, I'll send you a special version of 
>> >SERIAL.STX which prints to the screen what it sends out. Then we can 
>> >check what gets send, and see if it is wrong.
>> >
>> That would be a very awkward way of testing though.  Why not 'sprintf' to a
>> RAM buffer instead, and then write that buffer to disk.  This way I could
>> send you the results in meaningful form.  A bit like LOGSTIK results I mean.
>
>You're right, but it's more effort ;-) I'll do it like you suggested. 
>If you run MagiC on your Falcon I can even make it write from interupt, 
>not needing the RAM buffer.

Are you sure...?  I know bios and xbios are allowed in MagiC interrupts,
but I did not think gemdos was too.  I had a quick look in my docs now,
and though there was an entry on reentrancy, I could not find  anywhere
the explicit permission to use them in interrupts.  Hopefully you're right.


Ok, now for some news that I guess you will not like.  It appears that
Martin has found a way to protect against crashes during initialization
of 'custom' modules as well.  I'm not really surprised, because I had
also thought of a way to do it.  Even so, that was the last 'technical'
reason I could muster against his alternative.  The only other reason
remaining is the ability to use inflexible compilers with Pexec, but
I have already thought of ways to get around that too.  Since he is
quite smart (despite religious UNIX fixations), it is only question of
time before he does too.  When he does, or even before, he will force
a vote and demand a switch to custom loading.  And he will win.

Besides, if that protection method lives up to what he said, he really
has eliminated our main objections.  On the strength of smaller modules
we almost have to accept this now, without any strong counter-argument.

I suggest we agree immediately as soon as he demonstrates an actual
method to perform the crash-protection he spoke of having written.
That may eliminate some more of the bad feelings, and really convince
people that we did mean it when we said that nothing is rejected for
no reason.

I could do part of the work if you like, such as a relocating loader
etc, and then you can concentrate on the changes needed for modules.

Note that having made us accept _some_ custom format is one thing.
That does not at all mean it has to be according to his patterns.

I was thinking of a Pexec-like approach to simplify things:

The file format would still be identical to Atari executables.
This allows all compilers to be used.

The code is still started at the first word in the TEXT segment,
and we reserve the accumulated size of TEXT+DATA+BSS
Thus it would be very similar to a Pexec program, but without the
basepage.

A custom startup must be used, but needs do nothing.
The magic recognition is done by testinging a 'long' or two in what would
have been the program flags, which assures a sufficient difference from
the real executable format so that no program launcher will swallow it.
Finally, the Pterm/Ptermres calls must be replaced simply by RTS, with d0
carrying a long result value.  If negative this flags an error, if zero
this means success but that the whole module must stay resident, and if
larger than zero it means success with an ASM module needing only to keep
so much RAM as D0 says in staying resident.

The RAM block is then shrunk with Mshrink, which under these particular
circumstances will work fragment-free on all existing TOS.

The end result of this is that all necessary module changes are to create
that dummy startup object file, and changing the Pterm/Ptermres calls.

In most essentials you still have a system very similar to the present,
but without using Pexec, so nobody has anything to complain about.

What do you say ?
Should we go for this ?

If so, you might even announce it before Martin starts nagging again.

Sort of like:

After considering some of the ideas of Martin and the current design,
Ronald and I have thought of a way to retain much of the present code
and features while yet switching to a custom load system.  We hope
that this will satisfy those who wanted such a system, as well as
those who had no objections to the current implementation.  There will
be a few days delay before we can release new test versions, so please 
be patient.

All of the above are just suggestions.  The decision is yours.
If you do feel like announcing this go right ahead.
As soon as I notice this I will start the work I described above.

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