Małe "uaktualnienie" ;) 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.

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.

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.

Ja też poproszę.

Po półtora roku od ostatniego razu :) 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 :)

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.

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

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" :)

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

nowy ekran powitalny atari:

nowy znaczek atari:

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

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

> 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 f**k yea mam sektor 512b! problem rozwiazany!... co i tak nic nie zmienia bo problem jest nadal a dodatkowo pojawiaja sie jeszcze 3 kolejne :D

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

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