To: perot@pallas.amp.uni-hannover.de
Subject: Re: [2] New StiK (also Megafile 20)                                                 


On Mon, 23 Dec 1996 10:37:19 Peter Rottengatter <perot wrote: 
>
>On Mon, 23 Dec 1996, Ronald Andersson wrote:
>>
----- snip ----- re: LocalTalk on LAN and other ports

>> Yes, but I probably won't add any SCC to the Mega ST anyway.
>> Still, must the LCLTLK.STX really be port dependent...?
>
>Certainly not, I'm thinking about ways to recognize self-built ESCC-LAN 
>ports. But this is _very_ _very_ low priority. ;-)

I suppose this is mainly because even with RSVE/Bconmap support there is no
system function to control handshaking directly, or even determine if a given
port is capable of it.  One solution to this problem is simply to ignore it,
and assume that the port driver can handle this.  It would not be very hard
to add some handshaking for any serial port (including MIDI), simply by adding
a parallel port and modifying the driver accordingly.

Suppose one adds another MFP to a Falcon.  This gives the same serial ports
as a TT, and also adds a parallel port that can handle handshaking for itself
as well as for both MIDI and the ST_MFP serial port.  The net result of this
is five serial ports with full handshaking ability...!!!

Such a system would use the normal MFP_BAST.PRG and SCC.PRG, but would also
need modified versions of MFP_FALC.PRG and MIDI.PRG.  So the entire problem
could be solved by adding two more modules to HSMODEM.
This scheme is just one of many that would solve the problem by adding the
handshaking needed.

There is no need for the protocol to refuse using any port just because it
normally lacks handshake.  At most it should warn the user of this fact when
he selects such a port, but if he confirms that choice this should be taken
to mean that handshaking has somehow been added.

This should work fine for normal flow-control handshaking anyway.


>> LAN is just a serial interface after all, though I realize it may be hard
>> to adapt to the MIDI port, since that has no hardware handshaking lines.
>
>It's not possible to handle LocalTalk via the Midi port. It's not only 
>the handshake that is missing, also the ACIA is far to slow.

But that is _very_ easy to fix, though using very high speeds may require a
CPU accelerator anyway.  Also, even slow communication is better than none.
As long as both ends use the same speed it should not be a problem.
31250 bps is still more than twice the speed of my 14400 bps modem.  :-(


>The view of LAN just being another serial port is a bit too simple. Sure, 
>it is serial, but not like RS 232; it is RS 485 (if i didn't mix up 
>numbers ;-) ), which is a) differential drive, b) different voltages, 
>c) different impedances.

Sure, but that is just the physical interface, which can always be modified.
In my case the two computers stand on the same desk even, so the improved
transfer characteristic of RS 485 is not really needed here.  Often it can
be important, but not for short distances.  Both MIDI and RS 232 have pretty
good reliability at distances below 15 metres.


----- snip ----- re: Megafile 20 and SCSI drivers etc
>> 
>> Well, there may of course be some reason for his changed ideas,
>> but I have no experience with your drive so I can't really say.
>
>I asked him for such reasons but he wasn't able to produce any.

Then I suspect he simply did not want to bother with debugging this lack in
his driver.


----- snip ----- re: Megafile 20 & 30/60 Adaptek boards

>> Your drive is what some also call the 'Megafile 20', which means that the
>> ADAPTEK board uses MFM (the older standard) rather than RLL modulation.
>> So the 50% size increase will not be available with that board.  I have a
>
>Sure, I know these details. I'm just short of knowledge on board internals.

I have the schematics and hardware description, but no software description.
Some chips are used with which I am not familiar, so some of my opinions on
how the board works are just guesses.


----- snip ----- re: Megafile 30/60 changes for reliability with better drives

----- snip ----- re: Megafile 20 read data circuit description


----- snip ----- re: Harun's offensive answer to your bug report

>I got a reply from Harun. He seemed to have calmed down, and made a 
>hardly convincing attempt to justify his earlier mail, rather than 
>apologizing. Apologies don't buy anything ;-), so I just accepted it and 
>tried to discuss things again.

That was probably the best thing to do.  Both you and I and he all know that
the mistake was his, and that your report described something that really
needs to be changed.  Since we all know this anyway, it is unnecessary to
press him on the point.  That could even put an end to his new cooperative
mood, so it just isn't worth it.


>On the matter of the CPX he mentioned an FSERIAL.CPX by a guy called 
>Roman Bolek, which he said is more flexible, but not comprehensive and 
>even buggy. He got hold of the source code but said he doesn't have the 
>time to finish it. I asked him if there is any chance to get the source, 
>so that we do not need to start from scratch.

Actually I think that the solutions we've already discussed, combined with
the CPX you've already written, should solve this pretty conclusively.
Rewriting this other guys code to include our ideas might take even longer.
But I still agree that we should inspect the code if possible, since he may
have had some good ideas that we've missed, despite his 'buggy' implementation.


>PS.: are you interested in trying out a new STiK version. It's still not 
>     useful, but the threader probably is in the final stage, and I even 
>     finished the router and SLIP in SERIAL.STX.

Sure, and I would also like to see the current threader source again.


>     I am soon to start on a UDP module, which is quite a basic thing, and
>     then the big bug hunt starts.

I take it that means you will start to actually transceive packages then...?


>     When Dan got TCP ported, and Martin his resolve code put into an STX,
>     we're up to the functionality of old STiK !

Yep, but we should be able to start testing clients as soon as TCP is ready,
if we stick to pure IP numbers.  Most of the numbers we'll need for this can
be found in the DOMAIN.TXT file of old STiK.  We just need to make a dummy
'resolver' to begin with, that simulates the responses needed by clients.
At least I think this should work.

BTW, have you and Dan actually decided that he will port TCP, or did you just
assume so because he is the one best suited for it.  If he continues to be so
tied up by work and family obligations it may be necessary for another to try.


>     I will soon start to spread betas and also programming docs on a more 
>     regular basis, but I do not want to do this via the mailing list, 
>     and thus wait for Nick to have set up another beta list.

Good.  That should not take long, though it may perhaps be delayed a bit by
his trip to Sweden in a few days.

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