Return-Path: <perot@pallas.amp.uni-hannover.de>
Received: from mgate.uni-hannover.de (mgate.uni-hannover.de [130.75.2.3])
          by hugin.oden.se (8.8.4/8.8.4) with SMTP
	  id KAA32270 for <dlanor@oden.se>; Mon, 23 Dec 1996 10:33:54 +0100
Received: from pallas.amp.uni-hannover.de by mgate with SMTP (PP);
          Mon, 23 Dec 1996 10:36:20 +0100
Received: by pallas.amp.uni-hannover.de (AIX 3.2/UCB 5.64/4.03) id AA16185;
          Mon, 23 Dec 1996 10:37:20 +0100
Date: Mon, 23 Dec 1996 10:37:19 +0100 (MET)
From: Peter Rottengatter <perot@pallas.amp.uni-hannover.de>
To: Ronald Andersson <dlanor@oden.se>
Subject: Re: New StiK (also Megafile 20)
In-Reply-To: <199612222301.AAA25410@hugin.oden.se>
Message-Id: <Pine.A32.3.91.961223101032.18434B-100000@pallas.amp.uni-hannover.de>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 6c25156ab09e8e06ad927d83aa4e7465


On Mon, 23 Dec 1996, Ronald Andersson wrote:

> On Sun, 22 Dec 1996 18:24:09 Peter Rottengatter <perot wrote: 
> >
> >On Sun, 22 Dec 1996, Ronald Andersson wrote:
> >
> >> Once we have some improved clients for it, this would be a neat way to connect
> >> my Mega ST to my Falcon.  I use MIDI for this already, but have not found any
> >> network package sufficiently bugfree to leave it constantly active.  I've used
> >> DUET mostly, but since I discovered that this bombs whenever my modem activates
> >> RI (Ring Indicator) on Modem 2 I now only activate it when needed.
> >
> >I intent to have a LCLTLK.STX for all those machines with LAN port. This 
> >port can be used for a real more-than-two-machines bus, if an internal 
> >resistor is desoldered. Bad for you that a Mega ST doesn't have any LAN 
> >port, as LocalTalk is pretty fast. ;-)
> 
> 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. ;-)


> 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.

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.


> >> I could understand it if it was the Atari CDROM that was involved, since that
> >> is not compatible with normal CDROM commands, but the ADAPTEK board in Atari's
> >> Megafile 30/60 cabinet _is_ compatible with normal SCSI harddisk commands.
> >> Only the formatting/partitioning needs special attention, since the RLL drives
> >> used have no way of telling the controller their specific characteristics.
> >> Naturally not all commands are supported, but that is true of real SCSI drives
> >> too.  (eg: SCSI sector replacement operations are optional, some have none)
> >> 
> >> If his driver works at all through the ACSI port, I see no real reason why it
> >> should not also work with a Megafile.  BTW, I used to have a Megafile 30 that
> >> I rebuilt, mainly by adding an extra 60 MByte MFM drive from a PC XT.  With
> >> RLL modulation this drive gave 90 MByte so the net effect was a 'Megafile 120'.
> >
> >He told me that usually his driver works with every Megafile, not with 
> >the SH204 however. BTW. my drive is not the usual Megafile but a SH205, 
> >which he called almost indistinguishable on the software level. So he 
> >originally said it should work without trouble, it's been later when he 
> >changed his attitude and said he won't support old hardware anymore.
> 
> 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.


> >> NB: A trace on the adapter needs to be cut to achieve reliable use of 2 drives.
> >>     Maybe you already know this, but I have the info otherwise.
> >
> >It'd be lovely if you had any information that would enable me to make 
> >all that stuff work !! The SH205 too has an ADAPTEK host adapter, and for 
> >some time I operated the original drive as a second drive (good ole ST225), 
> >before it became too small and I threw it out.
> 
> 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.


> similar MFM board myself, but have never used it...!  I have not studied the
> MFM board in any detail, and don't know if it is  sufficiently compatible for
> the change I made to the 'Megafile 30' to be used with it.
> 
> 
> Here is a short description anyway:
> 
> Megafile 30/60
> --------------
> On the 20 line connector positive and inverted read data comes in from
> the drive on lines 17 and 18 respectively.  These two lines are connected
> to each other through a 100 ohm resistor and line 17 (RD+) is connected to
> ground through a 10 kohm resistor.  So far reality and schematic agree...
> But in reality there was also a shortcircuit from RD+ to ground, thus making
> the 10 kohm resistor useless and evidently overloading some types of drive.
> 
> That shorcircuit is a real (intended) trace situated near these resistors,
> and quite easy to cut.  Doing so had no noticeable effect on use of the
> original drive, but was necessary for the new drive to work reliably.
> Evidently the original (el cheapo) drive did not have proper differential
> drivers for read data, but better drives do and thus dislike the 'short'.
> 
> For drives without differential drivers the 'short' may help suppress noise
> but should not be necessary even then (was not needed in my Megafile).
> 
> 
> Megafile 20
> -----------
> Judging from my SH205 schematic there are completely separate data lines for
> the 20-line connectors of the two drives, and neither is grounded, but that
> 'short' to ground was not shown on the Megafile 30/60 schematic either.
> I'd check this with a multimeter rather than rely on any schematic.
> Apart from the two 100 ohm resistors, the read data is only connected to U11.
> (The 10 kohm resistors on line 17 are not present on this schematic)
> 
> J0 pin 17 connects to U11 pin 14
> J0 pin 18 connects to U11 pin 15
> J1 pin 17 connects to U11 pin 2
> J1 pin 18 connects to U11 pin 1
> 
> U11 pins 4 and 12 are enable signals for J1 and J0 respectively, since
> U11 converts the data to TTL levels at pins 3 (J1) and 13 (J0), which are
> shorted together to feed 3 TTL circuits with a common read data signal.
> Those 3 (U12, U16, U20) do some pulse separation/shaping and pass the signals
> to U29 (a 24 pin IC) which controls some rather complex external circuitry to
> do the real data/clock separation.  (Today most of this would be one IC)
> 
> 
> >> I've had that feeling too sometimes, when my debates have gotten a bit 'hot'.
> >> But two cases is much too small a sample to judge by anyway.  Some people are
> >> generally oversensitive, and if you catch these on a bad day there will be
> >> trouble regardless of style and phrasing (or even the topic).
> >
> >This is true. Thanks for all the words on this matter. Really sort of 
> >helped feel better. You noticed his opinion on the goals of new STiK. It 
> >seems to me that he excellently knows how networking works on Unix 
> >machines, and he desparately tries to apply that to the ST too. This must 
> >fail, as they are not even similar. Preemptive multitasking in both 
> >cases does not mean that such a thing can be done the same way on both 
> >systems.
> 
> I completely agree.
> Also, STiK should work without any multitasking (apart from ACCs) as well.

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.

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.


Cheers  Peter

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. I am soon to start on 
     a UDP module, which is quite a basic thing, and then the big bug 
     hunt starts. When Dan got TCP ported, and Martin his resolve code 
     put into an STX, we're up to the functionality of old STiK ! 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.

---------------------------------------------------------------------
   Peter Rottengatter             perot@pallas.amp.uni-hannover.de
---------------------------------------------------------------------

.
