Temat: SIO2BSD

To w zasadzie nie jest cały program, tylko coś poklejone na szybko, żeby działało. Miałem potrzebę uruchomienia połączenia Atari z pecetem przez SIO2PC pod FreeBSD; a okazało się, że nie ma żadnego oprogramowania. Wobec tego napisałem własny, bardzo prosty programik, który obsługuje transmisję. Program robi to, co od niego chcę, i nie będę już nad nim dalej pracował, ale może ktoś inny będzie chciał się pobawić, tak więc udostępniam niniejszym kod źrodłowy:

http://drac030.krap.pl/sio2bsd.tar.gz

Programiszcze kompiluje się i działa pod FreeBSD (sprawdzone pod 5.4) oraz, dzięki mikeyowi, pod Linuxem. Nie ma żadnego interfejsu sterującego ani plików konfiguracyjnych. Ścieżka dostępu do portu szeregowego jest zapisana na twardo w pliku sio2bsd.h (trzeba zmienić definicję stałej SERIAL). Poza tym do pracy w szybkiej transmisji niezbędne jest odpowiednie wykalibrowanie pętli opóźniającej; opis, jak to zrobić, jest w pliku sio2bsd.c, w komentarzach. Program jak widać jest niezbyt user-friendly.

Program działa z linii komend:

#./sio2bsd disk1.atr disk2.atr disk3.atr ... disk16.atr

Jeśli żaden parametr nie jest podany, program próbuje otworzyć plik 'test.atr' i przypisać go do D1.

Program działa w standardzie 19200, oraz ma 4 tryby turbo, z których można wybrać jeden w czasie kompilacji. Można też nie wybierać żadnego. Służą do tego flagi, które się wpisuje do Makefile:

1) bez flag - tylko standard 19200
2) -DXF551 - tryb XF551, 38400 bps. Ten tryb działa bardzo niestabilnie, w zasadzie tylko odczyt.
3) -DULTRA38400 - tryb UltraSpeed, 38400 bps. Działa dobrze (zapis/odczyt) pod SpartaDOS 3.2, moim OS-em dla 65c816, oraz QMEG-iem (jak twierdzi mikey).
4) -DULTRA57600 - tryb UltraSpeed, 57600 bps. Działa dobrze j/w oprócz SpartaDOS 3.2. Nie wiem w sumie, dlaczego pod SD 3.2 nie chodzi, ale nie chciało mi się w tym grzebać.

Pod SpartaDOS X jest oczywiście ten problem, że SIO tego DOS-u, mimo że pracuje w trybie Ultra, to ustawia zawsze na sztywno 52 kbps zamiast zapytać się stacji. Powiedziałbym, że jest to jedna z największych wad tego DOS-u. W takim układzie oczywiście Ultra nie będzie chodzić. Posiadacze QMEG-a oraz DracOS-a oraz SpartaDOS X 4.22 mogą oczywiście załadować sterownik SIO, który korzysta z SIO systemu operacyjnego. Wtedy powinno pójść gładko.

KMK
? HEX$(6670358)

2

Odp: SIO2BSD

Małe "uaktualnienie" wink Program powinien teraz dać się kompilować pod MiNT-em oraz na makowcu. Nie wiem tylko, czy działa, ale w zasadzie, po wykalibrowaniu, czemu miałby nie działać. Adres jak wyżej.

Zmiany:

- usunięty jeden czy dwa błędy
- procedura kalibrowania uproszczona (po ustawieniu PC_CLOCK kompiluje się całość, a potem odpala się komendę "time ./itprobe")
- wywołanie "./mkatr" wywołuje menuśko pozwalające tworzyć puste pliki ATR
- ./sio2bsd przyjmuje linię komend jak powyżej, ale jeśli zamiast nazwy pliku poda się minus, to odpowiadający mu napęd pozostanie nieprzypisany (przykłady w docu)
- dodane README
- dodane Makefile.Linux (copyright mikey) oraz Makefile.MiNT.

KMK
? HEX$(6670358)

3

Odp: SIO2BSD

Hmm, mamy więc możliwość odpalenia z ST/TT/Falcon wink

Sikor umarł...

4

Odp: SIO2BSD

Mimo że miałem już tego nie poprawiać, tutaj jest nieco uaktualniona wersja:

http://drac030.krap.pl/sio2bsd.tar.gz

Gdyby ktoś zechciał odświeżyć zawarte w archiwum Makefile.Linux i Makefile.MiNT, a przede wszystkim sprawdzić, czy toto w ogóle działa pod MiNT-em, to byłbym bardzo wdzięczny.

38400 chodzi dobrze, jednak przy przełączeniach pomiędzy 19200 a 38400 istnieją pewne zacięcia, których nie umiem zdiagnozować. Być może częściowo to wina peceta, albo kabelka COM2USB, którego używam.

KMK
? HEX$(6670358)

5

Odp: SIO2BSD

Nowa wersja pod adresem jak wyżej. Dodałem emulację P: i odczyt czasu/daty zgodny z APE. I coś tam jeszcze. Makefile poprawił jellonek (dzięki!) tak, że działa teraz zarówno pod Linuxem jak i pod FBSD, aczkolwiek w tym ostatnim wypadku trzeba użyć gmake (zamiast make) do kompilacji programu.

KMK
? HEX$(6670358)

6

Odp: SIO2BSD

Poszukuję chętnych na beta-testowanie nowej wersji. Dodałem coś w rodzaju PC-Mirrora, tzn. zamiast pliku ATR można podmontować katalog na dysku peceta.

KMK
? HEX$(6670358)

7

Odp: SIO2BSD

/me chetnie

8

Odp: SIO2BSD

Ja też poproszę.

hex, code and ror'n'rol!
"mężczyzna wydoił wielbłąda żoną"
"wcześniej miał na imię Heidi i był niemiecką kulomiotką"

9

Odp: SIO2BSD

mono: na irca hono...

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep

10

Odp: SIO2BSD

Po półtora roku od ostatniego razu smile upubliczniam kolejną wersję SIO2BSD:

http://drac030.krap.pl/sio2bsd.tar.gz

Jest nieco poprawek do głównego kodu obsługującego SIO. Kłopoty z uzyskaniem baudrate powyżej 38400 były, jak się okazało, powodowane przez kabelek COM2USB, po jego wymianie na FTDI (dzięki, mono!) ruszyło normalne 57600.

Wspomniane wyżej "coś w rodzaju PC-Mirrora" wyleciało z hukiem. Zamiast tego jest rozszerzenie, które nazwałem PCLink. W porównaniu do PC-Mirrora ma wady i zalety. Najpierw wady:

1) wymaga sterownika po stronie Atari. Takowy jest (w zasadzie) gotów dla SpartaDOS X 4.4

2) sterownik będzie przypuszczalnie, ale nie na pewno działał pod SDX 4.42, gdyż jego pojawienie się ujawniło konieczność wprowadzenia poprawek do DOS-u (usunięcia paru błędów i wprowadzenia pewnych rozszerzeń). Sterownik pewno wypuścimy prędzej czy później, razem z SDX 4.43 smile

Teraz zalety:

1) SpartaDOS za pośrednictwem tego sterownika oraz programu na PC (w tym przypadku SIO2BSD) widzi pliki (i katalogi) umieszczone na dysku peceta. W związku z tym można nimi manipulować z poziomu Atari przy użyciu najzwyklejszych na świecie komend typu COPY, MOVE, DEL, RMDIR, MKDIR itp.

2) przechowywane są (w obie strony) czas i data pliku

3) pliki binarne Atari można uruchamiać wprost z peceta, tak samo jak i wsadowe (jeśli ktoś lubi)

Całość działa w ten sposób, że przesyła do peceta nie komendy typu "wczytaj sektor nr xxxx", ale "otwórz plik o nazwie takiej to a takiej i prześlij uchwyt", "odczytaj tyle to a tyle bajtów z pliku o uchwycie tym i tym", "zamknij plik o uchwycie tym i tym".

Oczywiście program na pececie ogranicza dostęp Atari do wybranego przez usera podkatalogu.

SIO2BSD powinno dać się skompilować pod FreeBSD i Linuxem. Jeśli ktoś chce dostać sterownik pod SDX, to proszę o wiadomość na priv.

PS. Zapomniałem napisać, do czego to służy: otóż mnie na przykład służy znakomicie do backupowania twardego dysku, nareszcie można pliki po prostu (COPY /R) skopiować na peceta i tam zarchiwizować, zamiast bujać się z ATR-ami.

Ostatnio edytowany przez drac030 (2010-12-15 18:28:18)

KMK
? HEX$(6670358)

11

Odp: SIO2BSD

skoro nie przeszkadza ze po drugiej stronie kabla jest program na pc a na atari musi byc specjalny sterownik to moze
wkrotce mozna juz bedzie z poziomu atari obslugiwac baze sql ?

http://atari.pl/hsc/ad.php?i=1.

12

Odp: SIO2BSD

Oczywiście, że można, tylko po co?

"Physics is like sex: sure, it may give some practical results, but that's not why we do it." (Richard Feynman)
and... "Physics is to mathematics as sex is to masturbation." (podobno również R.F.)

13

Odp: SIO2BSD

Dokładnie, każdy tego typu program jest po coś. Dla mnie PCLink to łatwiejsze backupy i łatwiejsze kopiowanie danych do i z internetu. A jeśli ktoś chce sql, to niech zapyta Foxa, on mu udzieli dobrej rady, co z tym zrobić tongue

KMK
? HEX$(6670358)

14

Odp: SIO2BSD

Opis protokołu, według którego działa PCLink http://atariki.krap.pl/index.php/DOS2DOS

A pod tym samym adresem, co powyżej, nowsza wersja SIO2BSD - w PCLinku zapomniałem zaimplementować funkcję "rename" smile

KMK
? HEX$(6670358)

15

Odp: SIO2BSD

nareszcie krok w dobrym kierunku. cos co userzy komputera 'z okreslonego obozu' maja od zawsze (standardowa funkcjonalnosc) teraz okazuje sie byc wlasciwe tez dla atari.
czas najwyzszy przestac powielac opinie dzialu marketingu atari sprzed 30 lat jaki to atari os jest 'przemyslany', jest wiele do zmiany i ta zmiana jest jedna z wazniejszych. tylko jak zwykle, zmiana ewolucyjna czyli nakladka na nakladke, dobra idea a stare ramy. to musi byc zmiana rewolucyjna.

problemem malych komputerkow (jednym z wielu) jest dostepna pamiec:

1. pamiec operacyjna (dla procesora) - bardzo deficytowa a zwlaszcza na atari
2. pamiec masowa (trwala, dyskietki,dyski,sd,cd itd) ale rowniez ramdysk

w zastanej rzeczywistosci zeby wykonywac operacje na pamieci masowej trzeba do operacyjnej zaladowac program 'dos'  (urzadzenie d:) przez co tracimy okolo 8kb big_smile i tu potwierdza sie ze programisci atari to byly niezli jajcarze. jajcarze magicy, bo przekonali userow, ze tak ma byc i to jest dobre. w.mnie idea takiego dosa jest zla bo oprocz tego ze pozera pamiec operacyjna to naklada szereg ograniczen z ktorymi programisci walcza do dzis np. ilosc wpisow w katalogu, wielkosc pliku, kompatybilnosc itd. itd. itd. sterownik d: powinien umozliwiac operowanie na pamieci np:
wymioana danych:
- zaladuj dane z pamieci masowej do operacyjnej
- duplikuj dane w pamieci masowej itd. ale ciezar obslugi np filesystemu musi spoczywac na urzadzeniu do ktorego pamiec nalezy - w tym wypadku urzedzeniu zewnetrznym
ale rowniez np. mapowanie pamieci:
- np.alokuj 4x$1000 bloki pamieci masowej i mapuj na $C000 pamieci operacyjnej

z tymi zasadami wlasciwie zgodne mogly by byc urzadzenia takie jak ca2001 i ldw2000 z dodatkowa pamiecia, karin maxi, kmk/idea, sio2sd ale nie xf551 albo 1050

mozna to rozszerzyc na sio2pc a wtedy mozliwe bylo by rowniez oprocz powyzszych takze operowanie na bazach danych z poziomu atari albo obslugi sieci - bez koniecznosci ladowania jakis fikusnych dodatkowych sterownikow dla atari:)

zalety w stosunku do znanych na atari dosow:
1. brak ograniczen co do wielkosci pliku
2. brak ograniczen co do dlugosci nazw plikow
3. brak ograniczen co do wielkosci np. dyskow
4. niskie memlo nie do osiagniecia przez zaden dos
5. nowe mozliwosci :-)

dlatego trzymam kciuki bo byc moze przerodzi sie to w cos lepszego niz tylko nakladke na sparte do kopiowania plikow.

to mowilem ja, jarzabek waclaw.

---
to chyba moj najdluzszy post. uronilem lezke

Ostatnio edytowany przez xxl (2010-12-20 10:07:05)

http://atari.pl/hsc/ad.php?i=1.

16

Odp: SIO2BSD

Cieszę się, że ci się podoba.

KMK
? HEX$(6670358)

17

Odp: SIO2BSD

Czyli poprostu chcesz, żeby dos był w stacji ? Na commodore tego próbowali i chyba eksperyment się nie udał (1541) ? wink

What can be asserted without proof can be dismissed without proof.

18

Odp: SIO2BSD

nowy ekran powitalny atari:
http://images-mediawiki-sites.thefullwiki.org/06/1/9/5/9634021303521538.gif

nowy znaczek atari:
http://images-mediawiki-sites.thefullwiki.org/11/9/0/4/2956393648935614.jpg

przechodze na tumiwisizm

19

Odp: SIO2BSD

A to może Panowie Krytykanci napiszą jak wyobrażają sobie komunikację Atari z dowolnym innym systemem? Przecież mapowanie katalogów PC jako wirtualny ATR już było i więcej z tym kłopotu, niż pożytku. A tu jest mechanizm pozwalający na prostą, szybką (!) wymianę danych z innym kompem.

hex, code and ror'n'rol!
"mężczyzna wydoił wielbłąda żoną"
"wcześniej miał na imię Heidi i był niemiecką kulomiotką"

20

Odp: SIO2BSD

ale to nie jest krytycyzm dla Draca, tylko zapedow XXL'a
idealna platforma dla XXL'a to C128D z ULA

przechodze na tumiwisizm

21

Odp: SIO2BSD

w.mnie idea takiego dosa jest zla bo oprocz tego ze pozera pamiec operacyjna to naklada szereg ograniczen

Zgiń, przepadnij!

Idea dosa jest dobra, bo oprócz tego, że pożera pamięc, każdy może sobie zrobić dosa bez szeregu ograniczeń.

A gdybyś miał DOS w stacji to ograniczenia byś pokonywał wymieniając kostki?

Czy możecie wyjaśnić, Stirlitz, dlaczego wasz służbowy adres stirlitz@rsha.gov.de ma aliasa justas@gru.su?
Nie czytam PM. Proszę używać e-mail.

22

Odp: SIO2BSD

> ale to nie jest krytycyzm dla Draca, tylko zapedow XXL'a
> idealna platforma dla XXL'a to C128D z ULA

http://i61.photobucket.com/albums/h50/Szeszkin/1275389857_naked-gun-facepalm.gif

> Idea dosa jest dobra, bo oprócz tego, że pożera pamięc, każdy może sobie zrobić dosa bez szeregu ograniczeń.

w dosie siedzi diabel. mozesz sobie zrobic dosa z cala masa ograniczen, od czasu do czasu krzyknac fuck yea mam sektor 512b! problem rozwiazany!... co i tak nic nie zmienia bo problem jest nadal a dodatkowo pojawiaja sie jeszcze 3 kolejne big_smile

> Czyli poprostu chcesz, żeby dos był w stacji

nie, sterownik d: jest sterownikiem pamieci (program na atari), czesc odpowiedzialna za sama obsluge filesystemu musi spoczywac na urzadzeniu czyli jesli to ma byc ramdysk to nadal atari :-) ale juz bez tych narzutow ktore teraz stwarza dos, jesli to ma byc dysk pc to ... no? pc.

Ostatnio edytowany przez xxl (2010-12-20 12:17:05)

http://atari.pl/hsc/ad.php?i=1.

23

Odp: SIO2BSD

Przyznaję, że jeśli chodzi o ideę DOS-a wymyśloną przez Atari, wynalazek jest groźny smile Jakiś sterownik wprawdzie wciąż jest potrzebny, ale znacznie mniej skomplikowany i, gdyby ktoś chciał zrobić serwer plików na PBI, prawie całość można władować do ROM-u PBI. Albo wkompilowywać do binarek. I wtedy koniec z możliwością wyboru DOS-a, użytkownik jest skazany na coś w rodzaju tego, co mamy na C-64 albo ST (niemożność poprawienia DOS-u, bo jest w ROM-ie, ani biblioteki I/O, bo jest statycznie zlinkowana z milionem programów).

Moim zdaniem ideałem jest mieć jedno i drugie, tj. normalny DOS (wcale nie zajmuje 8 KB głównej pamięci, a jedynie do 6,5 KB - Sparta X ma standardowe memlo w okolicach $1000, czyli zajmuje 2,5 KB głównego RAM-u - plus oczywiście 1 bank ext smile ) obsługujący dysk lokalny oraz możliwość dostępu do dysków "sieciowych".

Głównym ograniczeniem DOS2DOS jest spory narzut "komunikacji służbowej". Można go oczywiście nieco zmniejszyć przez optymalizację protokołu, ale to będą, wydaje mi się, groszowe oszczędności. Żeby to uleczyć radykalnie, potrzebny jest po stronie Atari kod buforujący np. jednobajtowe operacje FREAD/FWRITE, no i bufory, a na to z kolei trzeba przeznaczyć cokolwiek RAM-u. Czyli DOS-a nie da się tak znowu prosto pozbyć, nawet jeśli się go statycznie wkompiluje do programu.

Ostatnio edytowany przez drac030 (2010-12-20 13:03:01)

KMK
? HEX$(6670358)

24

Odp: SIO2BSD

> Jakiś sterownik wprawdzie wciąż jest potrzebny, ale znacznie mniej skomplikowany

oczywiscie, sterownik taki moze zajac z 2kb ramu i moc obsluzyc rozne rodzaje nosnikow, rozne wielkosci, ramdysk, alokacje pamieci, nowe funcje (nie tylko pamiec masowa), byc odpornym na zmiane filesystemow :-) takiego sterownika nie trzeba by aktualizowac w przypadku gdy np.jakies urzadzenie bedzie mialo nowe funkcje itd.

> I wtedy koniec z możliwością wyboru DOS-a, użytkownik jest skazany na coś w rodzaju tego, co mamy na C-64 albo ST

co usera obchodzi jak skladowane sa dane? z punktu widzenia sterownika d: nic sie nie zmieni nawet jak zmienimy filesystem. interesuje nas kompatybilnosc na poziomie danych.

> Moim zdaniem ideałem jest mieć jedno i drugie,

zachowawcze podejscie, laczac metody poglebia sie wady pierwszego i radykalnie zmnniejszajac funkcjonalnosc drugiego.
chyba ze to ma byc forma przejsciowa przed ostrym cieciem - czas na dostosowanie oprogramowania.

> standardowe memlo w okolicach $1000, czyli zajmuje 2,5 KB głównego RAM-u - plus oczywiście 1 bank ext

czyli 2,5 + 16kb
daleko szukac, to tez jest wada, zalozmy ze konfiguruje memacA na $4000 i przeprowadzam ladowanie do pamieci VBXE... oooopsss, sparta sie zawiesila sad potrzebna aktualizacja dosa czyli wymiana albo przeflashowanie kostki, dos (w starym rozumieniu) powinien sprawdzac rozszerzenie pamieci vbxe.
 
w przypadku o ktorym wyzej rozmawiamy takich niespodzianek wogole by nie bylo.

> Głównym ograniczeniem DOS2DOS jest spory narzut "komunikacji służbowej".
> Czyli DOS-a nie da się tak znowu prosto pozbyć, nawet jeśli się go statycznie wkompiluje do programu.
 
nie jestem przekonany, wydaje mi sie za to ze wlasnieu 'ogladanie sie' na dosa generuje naddatki kodu.

ostatnio wlasnie sie zastanawialem zeby przejsc na pisanie programow 'calodyskowych' gdzie sterownik moze zajac 1kb, mozemy komunikowac sie z pamiecia masowa, pozbywamy sie co prawda filesystemu ale zyskamy np alokacje pamieci... tylko ze to tez nie jest idealne i w przypadku gdy powyzszy pomysl wypali traci racje bytu.
dlatego trzymam kciuki mocniej bo mam nadzieje bedzie to rewolucyjna zmiana.

Ostatnio edytowany przez xxl (2010-12-20 14:01:56)

http://atari.pl/hsc/ad.php?i=1.

25

Odp: SIO2BSD

xxl napisał/a:

oczywiscie, sterownik taki moze zajac z 2kb ramu i moc obsluzyc rozne rodzaje nosnikow, rozne wielkosci, ramdysk, alokacje pamieci, nowe funcje (nie tylko pamiec masowa), byc odpornym na zmiane filesystemow

Opisujesz SpartaDOS X. Niestety, tego (zwł. obsługi ramdysku i alokacji pamięci, buforów I/O) raczej się nie zmieści w 2 KB. Sama obsługa tego protokołu to nieco ponad 1 KB kodu, a to nie jest "goły" moduł, tylko sterownik obudowany całym DOS-em (który np. załatwia wyżej wspomniane buforowanie).

Dodam że SDX jest tak skonstruowane, że od biedy można byłoby w ten sposób w ogóle przekierować całą obsługę dysków na zewnątrz przez taki sterownik. Tylko nie ma po co, lokalny twardy dysk jest o wiele lepszy.

xxl napisał/a:

co usera obchodzi jak skladowane sa dane?

Obchodzi, jeśli ma pamięć masową, do której nie sięga wyobraźnia autora programu (e.g. całodyskowy SynFile vs stacja 720k).

xxl napisał/a:

daleko szukac, to tez jest wada, zalozmy ze konfiguruje memacA na $4000 i przeprowadzam ladowanie do pamieci VBXE... oooopsss, sparta sie zawiesila sad potrzebna aktualizacja dosa

Nie, po prostu musisz uważać, gdzie i jak ładujesz dane. Przy ładowaniu tak samo nie możesz nadpisać inicjalizera, wektorów przerwań, rejestrów I/O - a przy twoim pomyśle, sterownika oraz "zaalokowanej pamięci", którą ma on wg ciebie serwować. Przy ładowaniu danych pod ROM też trzeba to robić w określony sposób (mimo że tych sposobów może być kilka). Więc takie uważanie to (nie powinno być) nic nowego. Ot takie podstawy tego, co powinien umieć koder.

Ostatnio edytowany przez drac030 (2010-12-20 14:42:39)

KMK
? HEX$(6670358)