🚀 go-pugleaf

"J.F" <jfox_xnospamx@poczta.onet.pl> writes:

> Modem DCE2 sie przestawia na odbior, tyle tylko, ze juz byl w trybie
> odbioru.

Nie ma czegoś takiego (w full dupleksie), że modem się przestawia na
odbiór albo na nadawanie.

> Zeby to zadziałalo, musisz mocno przedefiniowac sterowanie modemem, 
> bo to juz ani RS-232, ani V.24.

Nic z tych rzeczy. Przyznaję, w RS-232 z 1960 r. tego nie było, ale
później - bez przesady:

V.24 circuit 133, RS-232 circuit CJ, DB-25 pin 4.

Direction: TO DCE
This circuit is used to control the transfer of data (flow control) on
Circuit BB (Received Data) when an intermediate function such as error
control is being used in the DCE.

The ON condition on Circuit CJ (Ready for Receiving) indicates that the
DTE is capable of receiving data.

The OFF condition indicates that the DTE is not capable of receiving
data and causes the DCE, or the intermediate function, to retain the
data. In some DCEs the OFF condition on Circuit CJ (Ready for Receiving)
also causes a signal to be transmitted to the distant DTE causing an OFF
condition to be placed on Circuit CB (Clear to Send) extending the flow
control to distant DTE.

> 8250 byly IMHO wystarczająco szybkie - tam byl inny problem, OIDP - 
> nie bylo sygnalu dla procesora, ze wysyłanie sie zakonczyło, 
> wiec mozna juz zdjac sygnal RTS. 
> Typowym modemom nie przeszkadzalo, tylko jakims half-duples
> (radiomodemy?) i do dzis RS-485.

Nie, 8250 ani 16450 nie były "wystarczająco szybkie". To były scalaki
podpięte do szyny ISA (a właściwie XT-BUS), czasy dostępu (zwłaszcza
8250) typu setek ns, były w stanie "zbuforować" ok. jednego bajta
danych, co oznaczało - przy np. szybkości 115200 bps - kilkadziesiąt,
a przynajmniej kilkanaście tysięcy przerwań/sekundę. I to pod warunkiem,
że opóźnienie obsługi nie przekroczy kilkudziesięciu us (dolicz do tego
zależności czasowe generowane np. przez twarde dyski). To po prostu nie
miało prawa działać, chyba że w systemie, który niczego innego w czasie
transmisji nie robił.

Praktyka była taka, że 16450 działały "od biedy" @ 38400 bps, natomiast
8250 @ 9600 bps (albo i nie) - to ostatnie mogło być spowodowane nie
tylko samym scalakiem, ale także konstrukcją karty wieloportowej, której
używałem (jednakże 8250 były wolniejsze i mogły wymagać dodatkowych wait
statów na ISA itp).

Natomiast takiego czegoś, o czym napisałeś, to ja nie kojarzę.
Nie żeby to miało związek z modemami, ale wszystkie te scalaki miały
flagi (sprawdzam: bit 5 w LSR) "Transmit Holding Register Empty" oraz
(bit 6) "Transmitter Empty", i bez problemu można było ich użyć do
sterowania (programowego) RTSem.
Nie robiły tego sprzętowo, owszem. Takie np. Oxfordy (opcjonalnie)
robią.

"bit 6: This is the Transmitter Empty flag. It is 1
when both the THR (or transmitter’s FIFO) and
the TSR are empty. Reading this bit as 1 means
that no transmission is currently taking place in
the txd output pin, the transmission line is idle."

> 16550 problem mial wiekszy, bo kolejka dluzsza, ale to tylko
> kilkanascie bajtow.

NS16550 miał problem taki, że nie dało się skorzystać z jego FIFO.
16550A i późniejsze były poprawione i działały.

> Ale chodzi o DCE. Łatwo mozna GB transmitowac, a działało, bo:
> -predkosc portu modemu wczesnie wzrosła, i z transmisją 
> modem->komputer nie bylo problemu,

Ale gdyby była, to pecet zdejmował RTS, i wciąż nie było problemu.
W szczególności z 16550A+, ze względu na FIFO.

> -wąskim gardłem zrobiło sie polączenie modem-modem,

To zawsze było wąskim gardłem raczej, nie?
Połączenie DCE-DTE raczej nigdy nie było wolniejsze niż DCE-DCE.


To działało, bo po prostu handshaking RTS/CTS działał.
-- 
Krzysztof Hałasa