On Sat, 10 Sep 2022 23:24:37 +0200, Krzysztof Halasa wrote:
> "J.F" <j...@p...onet.pl> writes:
>>> Możesz do tego dodać jeszcze "block transfers" (ATA-2 IIRC), aczkolwiek
>>> możliwe, że to było już na płytach z Super I/O z FIFO.
>>
>> Masz na mysli wiele sektorow na raz?
>
> Owszem, w przypadku niektórych dysków (ale IIRC nie WD) nieco
> przyspieszało to transfery.

Ogolnie powinno przyspieszyc, ale tylko nieco. O co tym WD poszlo ?

>> W to juz nie wnikalem - ale jak kontrolery, a w zasadzie interfejsy
>> ATA byly na plycie - to nie pojawilo sie jakies "nieoficjalne DMA" ?
>> W sensie, ze hardware na chipsecie transmituje sektory, bez
>> angazowania procesora?
>
> Nie, pojawiło się raczej "oficjalne" DMA.

W to juz nie wchodzilem, ale tych poziomow PIO bylo kilka,
i kilka UDMA.
Czy dla dysku byla jakas roznica, czy to PIO czy DMA, czy tylko o
predkosci/czasy tu chodzi ?

Bo az sie prosi do "zwyklego trybu PIO", dorobic jakis sprzetowy
interfers z DMA czy bus master.

>> Dioda w jumperku ... na to nie wpadlem, ale mogloby zadzialac
>> Tylko jeszcze jakis pull-down trzeba by dorobic.
>
> Był na płycie.

Byl pull-up. I stad cale zamieszanie.

>> "Reportedly, a third-party communication port driver (such as
>> TurboComm) is required to run Kermit at speeds greater than 9600 bps
>> under Windows 3.0.
>> A 16550a UART helps too, for its FIFO buffering.
>
> Przyznaję, że Windows mnie nie interesowały specjalnie - userom
> wystarczał trumpet winsock i jego obsługa (jednego) modemu (z typowym
> logowaniem i następnie PPP).

Jakos tak, ale byl jeszcze RAS na NT.

>> "On IBM PCs and PS/2s with IBM asynchronous adapters, Kermit can be
>> used at speeds up to 57600 bps under DOS (under Windows or DesqView,
>> the maximum speed is probably lower). 115200 bps works only with a
>> very short shielded cable, and the async adapters of the two machines
>> in perfect tune.
>
> To jakieś aberacje, problemy "analogowe" miały się nijak do FIFO itp.

Tez mi sie tak wydaje.

> Może autor miał jakieś cyrki z uziemieniem komputerów, to przeszkadzało
> w takich transmisjach (bezpośrednich).

Mozliwe. Tak czy inaczej - przy pewnej dlugosci kabla 115200 juz nie
przejdzie, ale czy to bedzie "krotki kabel" ?
Cos mi chodzi po glowie, w standardzie bylo max 15m dlugosci, do
polaczenia modemu starczy, ale moze oni mieli dluzsze kable,
miedzybudynkowe np.

> Plus problem "zasilania z różnych
> faz" (w rzeczywistości pozorny, wynikający ze złego/braku uziemienia lub
> zerowania).
>
>> Some VAX serial port interfaces are out of tolerance
>> at 19,200 bps and faster."
>
> Tak mogło być, różne komputery używały różnych kwarców i dzielników.
> Akurat w pecetach wystarczało (dokładnie) do 115200 bps, ale nie
> wszędzie tak było.

>> Ale o co chodzi z tym "tune" to nie rozumiem.
>
> Kwestia dokładności bitrate.
> Jak np. miałeś kwarc 4 MHz, z podziałem przez 16 (próbkowanie itp), to
> błąd przy 9600 i 19200 był mniejszy niż 2 promile (bez problemu). Ale
> już przy 38400 było to 7% i niestety odbiornik nie był w stanie tego
> odebrać.

Calkiem mozliwe, ale co - peceta zrobili "dokladnie", a Vaxa nie?

No chyba ze Vax byl projektowany na max 9600, i uzywal wtedy
nieparzystego podzielnika, dalo sie wycisnac wiecej, ale juz nie
19200?

No chyba, ze zaoszczedzili kwarca, mieli jakis systemowy zegar
np te 4MHz, 9600 robilo sie z drobną odchyłką, a 19200 juz niedrobną.

> Przy 8 MHz 38400 było ok, ale 57600 i 115200 - nie, itd.

no nie wiem czy to mozna "out of tune" nazwac,
ale faktycznie 8M/16/13=38461,
8M/16/9 = 55555

Ma szanse zadzialac z 57600.

> W niektórych sytuacjach dawało się ustawić wewnętrzny podział przez
> 8 zamiast 16, co pozwalało uzyskać 2x większe szybkości.
>
> To był dość typowy problem w różnych maszynkach, chociaż w pecetach
> raczej mało znany.

Pecet to jakos lepiej zrobil, ale fakt - po 38400 powinno byc 76800,
a tego pecet nie potrafi.

J.