Użytkownik "J.F." <j...@p...onet.pl> napisał w wiadomości
news:1t06y4d7b4btn$.1e8lpn3n2yuno.dlg@40tude.net...
>> Ale tak że 1200 to może? :)
>
> Mnie o rozmiar pamieci chodzi.

Myślę, że gdyby kompilator nie rozwlekał kodu takiego jak ten (chodzi mi o
objętość źródła):
begin;
writeln ('Dzień dobry wieczór bardzo');
end.
do ponad 100 kB, czy w ogóle, to dało by się to zrealizować.
W końcu Packet-Radio na C64 działa i to program nie ułomek (choć nie bez
wad), są programy BBS-ów radiowych, BBS-ów telefonicznych, C64, ze względu
chyba na konstrukcję systemu plików 1541, uzywa do plików protokołu Punter,
hasło wiki nie podaje tego, ale ZTCP, było chyba w ktrymś Bajtku coś, co na
to wskazuje.
https://en.wikipedia.org/wiki/Punter_(protocol)
(dostawić nawias w adresie, jeśli wyrzuci brak strony)

>
>> Ja w każdym razie, już w '93, hmm... bodajze z Maloki, ale pewności nie
>> mam,
>> no, ćwierć wieku... na pracowym kompie (do synchronizacji zegarynki z
>> serwerem czasu w Dallas), miałem 386, DOS, z 1 MB (tak, mega, nie
>> giga-bajtem), 40 MB HDD i całkiem sporo się zmieściło, z gołymi babami z
>> BBSów i nie tylko :)...
>
> A tu mamy 64KB RAM+ROM.

Nie wydaje mi się to istotnym ograniczeniem. Może jakieś wersje rozwojowe,
to tak, ale mam wrażenie, że powinno dać sie zrobić, przynajmniej wersja
podstawowa.

>
> No i to byly zlote czasy dla modemow, a teraz ... a co to jest modem ?
> Juz nawet nie pamietam kiey ostatni raz uzywalem :-(
>
>> ZTCP. C64, oparty na 6502, może max wyciągnąć 2400, własnymi
>> możliwościami.
>
> O ile pamietam, to stacja dyskow byla na laczu szeregowym, i dawala
> sie przeprogramowac na 19200, bo normalnie to byl tragicznie wolna :-)

Tak, oryginalnie jest ok. 4 kbps. Jako ciekawostkę niepotwierdzoną podam, że
pasjonaci z powodzeniem żenili 1541 z komputerem ZX Spectrum.
Owo 19200, jeśli, to zmianami rejestrów, ale nie sądzę, żeby aż taki narzut,
prędzej modyfikacja (albo nowy) program obsługi. Transmisja z poziomu
"maintenance" szła raczej z fabrycznym 4 kbps.
A Warp, jak łatwo policzyć, wyciągał do ok. 100 (z moich szacunków, ok. 98
kbps, ale to szacunki były, musiałbym dokładniej to pomierzyć) kbps, więc
dawało się to zrobić. Zdaje mi się, ze prócz linii danych, zaprzęgano do
tego linię zegara, więc na każdą z linii wychodziło ok. 50 kbps, więc procek
miał już wtedy ok. 20 cykli, aby to obrobić.

>
> ten procesor robi ok 1 MIPS, to mamy ok 500 rozkazow na bajt - az za
> duzo, wiec to nie koniec mozliwosci.

Myślę, że to raczej nie w tym rzecz była... stacja Atari, fabrycznie miała
19200, a też na łączu szeregowym przecież.
Zbadałbym, czy to nie z powodu nośnika, który na początku mógł nie należeć
do najlepszych, programy jeszcze tak dobrze nie zoptymalizowane, do tego,
coś działającego trzeba było na rynek wypuścić, stąd wolniejsza transmisja,
mnie to raczej polityką (ale nie typu przywódcy państwowi, lecz działania
korporacynje) firmy śmierdziało, na zasadzie pośrodkowania pewne-szybkie.
Gdybam tylko.

>
>> Nie powiem, na ile dałby więcej portem równoległym, w każdym razie,
>> transfer
>> dyskowy, fabrycznie ok. 4 kbps, w trybie warp szedł ok. 100 kbps (tak,
>> sto
>> kilobitów na sekundę), dając prockowi jedynie 10 cykli na 1 bit
>> transmisji,
>> zaznaczam, na łaczu szeregowym.
>
> Ktore ma sprzetowy rejestr i w koncu mamy 80 cykli na bajt.

Ale jakoś trzeba do tego rejestru wpisać... Nie pamiętam teraz, na ile
sprzętowo.

>
> No chyba, ze nie ma, i czysto programowo wachlujemy jednym bitem?

Ja podejrzewam, ze jednak jest to coś takiego. Inaczej część zabaw
niskopoziomowych, nie musiała by być robiona na fabrycznej prędkości
transmisji.

>
> Tak nawiasem mowiac - pamietam jakis system monitorujacy na 8080.
> Modem 9600 ... ale wiele ich.
> No i tak liczymy - od jednego przerwanie co 1ms, zanim przerwanie
> przyjmiemy, zrzucimy rejestry, sprawdzimy ktory port, odtworzymy ...
> no zabraknie czasu przy 10 modemach.
> W efekcie przerwanie bylo zegarowe co ok 0.5ms, sprawdzalo polingiem
> wszystkie porty.

I tak bez buforowania? Bo niby nie ma tu tak dużo (że ma przy 10 zabraknąć
czasu), a jednak się zapycha.
Gorąc jest, myslenie na 10 % zaledwie...

>
>> Oczywiście, wiadomo, WARP jest obłożony kosztami takiej imprezy,
>> nietrudno
>> się domyślić jakimi, choć podstawowa kontrola błędów jest zachowana (nie
>> w
>> każdej realizacji). W trybie WARP można też zrobić kopiowanie dyskietek,
>> leci OIDP, z ok. 20-krotnym przyspieszeniem. Gdyby mój laptop miał mieć
>> podobną wydolność transfery z dyskiem, to powinien ciąć, zakładając
>> szeregowe łącze i WARP, 2x2.8=5.6, czyli jakieś 560 Mbps.
>
> Tak nawiasem mowiac, to IBM sie nacial podobnie.
> DMA w 8088/86/286 bylo za wolne, i AT z HDD komunikowal sie rozkazami
> OUTR/INR

Trochę nie tak... Niejasno napisałem "ciąć", w sensie, pruć jak nóż. A do
skakania transferu powinno być raczej "przycinać". Miałem na myśli, ze mój
lapek, pruł by pół giga, jeśli WARP nie byłby pełny i zostawił prockowi
trochę czasu na ekran (bo co po DMA, jak jakoś trzeba układom zadać, co i
gdzie mają przesłać, a tego bez procka raczej się nie da). Prędzej mechanika
dysku by nie wyrobiła, bo czas pozycjonera jednak jest skończony i tym
większy, im dalej głowica musi skoczyć. Zresztą, w 1541 też występował
problem fragmentacji i narastającego przez to czasu transmisji pliku, ale
tam sprawa była dość prosta i dawało się to poukładać ręcznie, jeśli ktoś
miał sierpliwość bawić się 664 blokami (albo 1328 dla 1571/1572) i wiedział,
jak jest skonstruowany system plików.
Co do dysku w AT - to dziś by nie poszedł? Nie było tak dedykowanych kart do
obsługi dysku? Czy mówimy o starociach, jak ST225, czy o nowszych, zgodnych
raczej z "autobusem"?

--
Łapy, łapy, cztery łapy,
A na łapach pies kudłaty.
Kto dogoni psa? Kto dogoni psa?
Może ty? Może ty? Może jednak ja...?