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


On Wed, 25 Dec 1996 18:21:20 Peter Rottengatter <perot wrote: 
>
>On Tue, 24 Dec 1996, Ronald Andersson wrote:
>>
----- snip ----->> re: Extended serial ports with handshaking
>
>Sounds nice ! Only trouble is you need to talk Harun into adding HSMODEM 
>modules.

Yes, but if he refuses it should not be all that hard to disassemble one of
the existing modules, and then add/alter the handshaking parts.


----- snip ----->> re: Assuming handshaking present on all ports
>
>Agreed completely. Note that I only ignore Midi if I must assume that it 
>is gonna be blocking, i.e. without HSMODEM. Ignoring handshake is 
>precisely my approach. I simply say it's the drivers and the MODEM.CPX 
>(thus the user's) business to ensure handshake is switched on, or that 
>the hardware somehow doesn't need handshake.

Good.  Evidently I misunderstood part of your earlier answer.


----- snip ----- re: speed problem with LocalTalk for MIDI
>> 
>> But that is _very_ easy to fix, though using very high speeds may require a
>
>What do you mean ? Running the ACIA with the appropriate clock ? It won't 
>survive it I suppose. And you need a _very_ fast CPU accellerator, as the 
>ACIAs share a problem with the MFP, which is the on-byte receive buffer.

I take it you never read Motorola's 6850 specification...
The normal 6850 is guaranteed to handle 500 kbps !!!
But I suppose the MIDI drivers could limit that a bit, since they essentially
function like open-collector drivers with pullup resistors (giving rise delay).

That specification was written in the late 70's, so I wouldn't be surprised
if a 6850 manufactured today can use considerably higher speeds even.

The one-byte buffer is indeed another limiting factor, but since Harun has
managed to use the MFP at 57600 bps, the same should be possible with MIDI.


>> CPU accelerator anyway.  Also, even slow communication is better than none.
>
>Sure. I'm not saying Midi should not be used (after all, it's twice as 
>fast as an unmodified Modem 1), just that you can't use the Midi hardware 
>for LocalTalk.

Why not ?
The original MIDI port can only be connected to another MIDI port, and when
both computers use the same kind of port and the same speed there should be
no problem, even if the protocol 'normally' uses another speed.  A modified
port with handshake lines added should work fine with any opposite port using
the same speed and a compatible handshake.


>> >[ the Megafile issue ]
>
>I have some description too, but no schematics. However I guess it's 
>gonna be hard to find the problem by hardware means. And this still 
>doesn't mean that the guy would fix his software.

True.  The only thing likely to make him do that would be if several users
demanded it, which is rather unlikely to happen.


----- snip ----- re: FSERIAL.CPX by Roman Bolek
> 
>The CPX I wrote doesn't deal with interface parameter, like speed, and 
>handshake. It was my intention to leave this specifically to specialized 
>CPX, like the MODEM.CPX, as other interfaces will need other parameters and 
>thus other CPX again.

Oh, in that case we should definitely have a long hard look at his source,
and either debug it or use the vital parts for a CPX of our own.  He really
should not mind letting us do this, if he has left it as-is for lack of
time to do it himself.


----- snip ----- re: new STiK beta
>
>Ok, I got an update for the things I've sent to Dan, to support his 
>porting of TCP. You'll get the same package. The threader source is not 
>included however. I'll send that later.

Fine, I'll get back to you with some feedback later then.


----- snip ----- re: new STiK soon testable on Internet
>>
>> 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.
>
>This is already in RESOLVE.STX ;-)

Good !  Then it should support all clients that can work with numeric IPs only,
as soon as TCP has been ported to an STX module.


----- snip ----- re: Porting of TCP to be done by Dan ?
>
>The other day he asked what he could start with. I was amazed by that, 
>and started immediately to put together what he needs, to not hamper his 
>enthusiasm ;-)

Great.  Having both of you working on the STX's should cut down development
time, so that we can soon start using the new STiK for real communication.

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