Zapewne ;)

Inty się w innych basicach chyba oznacza przez % (np. WYNIK = 0 to real, a WYNIK% = 0 to int). W Acornie BBC taki int to liczba 32-bitowa ze znakiem. Jak proponujesz deklarować inty o różnej wielkości, albo np. ze znakiem i bez?

Ktoś wie, jak to jest zrobione w GFA?

Badów nie bada :) Sprawdza tylko, czy się pierwszy sektor dysku czyta i zapisuje. Jak nie, to mówi, że dysk jest do bani.

Skanowanie całości dysku na okoliczność badów mogę dodać.

FDISK II będzie miał support dla sektorów 128 (BIOS v. >= 1.8), 256 i 512 bajtów. Większe rozmiary sektora zależą od tego, jak będzie w końcu wyglądał BIOS v.2.0. Support dla dwóch dysków już jest, dysk do partycjonowania wybiera się z menu ukazującego się na początku. Menu główne podaje rozmiary partycji w sektorach fizycznych (po 512 B) i logicznych (tak jak widzi SIO), rozmiar sektora logicznego itp. Będzie można zarezerwować więcej niż jeden sektor na MBR. No i postaram się, żeby ta wersja FDISK-a chodziła na XEP-ie.

dely: z tego co mi wiadomo, do desktopu Pinka potrzebny jest szybki twardziel, bo ten program w kółko coś czyta z dysku. Jak masz twardysk i odczyt 50 kilo na sekundę, to się tego nie widzi :)

No, po pierwsze, mają SIO2IDE. Na AtariAge widać, że już ktoś tam to sobie złożył. A co do interfejsu z transmisją równoległą, ci "mieszkający poza Polską i Niemcami" nie mają alternatywy, bo - tak mi wygląda - najwyraźniej niczego lepszego opracować nie umieją.

Wystarczy zresztą rzucić okiem na tematy poruszane na comp.sys.atari.8bit, oraz większą część wątków na AtariAge, żeby się przekonać, iż mimo że komputer ma blisko 30 lat, jego posiadacze i "miłośnicy" w przeważającej części nie mają o jego konstrukcji bladego pojęcia; po MyIDE sądząc, autor myśli, że jest to coś w rodzaju ZX Spectrum, gdzie podobne rozwiązania są na porządku dziennym, jak to było widać na Foreverze.

Narzekacie, że KMK/JŻ IDE jest "drogie", chociaż, jak mówię, niejeden za stację dysków zapłacił dwa razy tyle. Ale tego typu rozwiązanie - to znaczy "nowe urządzenie" zapewniające dodatkowo 16-bitowy odczyt i zapis - jest rozwiązaniem jedynie przyzwoitym. Jeśli ktoś zrobi to samo np. dwa razy taniej, jeśli chodzi o koszty tzw. własne, osobiście postawię mu ramkę "Zywca" i pochylę czoła w uznaniu zasług.

Nic natomiast nie skłoni mnie do uznania, że szałas związany sznurkiem jest równie wspaniały co porządna chałupa, bo szałas ma przygniatającą przewagę w cenie. Kto mieszkał w szałasie i w porządnej chałupie, ten wie, że to bzdury.

I tak to wygląda z mojej perspektywy :)

BlackBoxa w Polsce chyba nie ma nikt (ale może się mylę). Z ludzi widywanych na tym forum ma to o ile się nie mylę TXG, a Nir Dary to na pewno. Poza tym BB ma to samo, co KMK/JZ IDE, mianowicie albo potrzebne jest 130XE, albo ręczne strojenie. No i nie jest taki szybki, a dyski SCSI są trudniej dostępne niż IDE.

Rozszerzenie sterownika SPARTA.SYS oraz filesystemu Sparty pozwalające na pracę z sektorami 512-bajtowymi. To już jakiś czas trwa, może do wersji 4.30 (czy ile tam trub nada) jeszcze nie wejdzie, ale do 5.0 na pewno ;) Na razie nie chce mi działać nowy sterownik interfejsu i nie wiem czemu, ale się pewnie wkrótce dowiem ;)

No tak, ale najszybsze to to nie jest.

Raczej nie, interpreter tego za ciebie nie zrobi. Jeśli chcesz dostawiać wiersze tekstu w środek pliku, to trudno darmo, musisz kopiować. Ewentualnie możesz to jakoś załatwić znacznikami, to znaczy na początku pliku rezerwujesz miejsce na wskaźniki do poszczególnych wierszy (np. 256 wskaźników), i jak chcesz dopisać coś w środek, to dopisujesz fizycznie na końcu i tylko poprawiasz tablicę wskaźników tak, żeby przy sekwencyjnym czytaniu ta dopisana linia wypadała tam gdzie powinna. Oczywiście po jakimś czasie przy czytaniu takiego pliku "sekwencyjnie" głowica dysku będzie fruwać w tę i we wtę po całości, ale z twardzielem to nie taki znowu problem ;)

Nie widzę tu żadnego błędu, program zachowuje się dokładnie tak, jak mu kazałeś. Najpierw generujesz 15 "wierszy" tekstu (for b=1 to 15:? #1;b:next b), gdzie każdy wiersz zaczyna się od liczby zapisanej cyframi ASCII, a kończy się znakiem RETURN - bo tak działa instrukcja PRINT. Daje to plik tekstowy o długości 36 bajtów (9*2 + 6*3 = 36).

Następnie otwierasz tenże plik do wymiany danych, wczytujesz przez INPUT siedem pierwszych wierszy pliku. A więc w tym momencie znacznik odczytu i zapisu wskazuje na początek wiersza ósmego, tego zaczynającego się od cyfry "8". Dalej każesz zapisać trzy ciągi tekstowe "$0001", "$0002", "$0003". Ponieważ zapisujesz je instrukcją PRINT, więc każdy z nich kończy się przez znak RETURN, i ma nie pięć, tylko sześć znaków długości. Przeto ciąg binarny:

$38,EOL,$39,EOL,$31,$30,EOL,$31,$31,EOL,$31,$32,EOL,$31,$33,EOL,$31,$34,EOL,$31,$35,EOL

nadpisywany jest przez:

$24,$30,$30,$30,$31,EOL,$24,$30,$30,$30,$32,EOL,$24,$30,$30,$30,$33,EOL,EOL,$31,$35,EOL

Ostatni wiersz (ten zaczynający się od "15") wcale się nie przesuwa ani nie ma żadnych dodatkowych linii, ani nic niczego nie "wpi*". Po prostu koniec ostatniego ciągu hex (jego EOL) wypada w miejscu, gdzie poprzednio była cyfra "4" (ze stringu "14"). Dlatego masz ten odstęp. Ale nie ma tu żadnego błędu, wszystko jest OK, i nie ma czego paczować - moim zdaniem.

Jeśli chcesz uniknąć wpisywania przez system dodatkowych znaków EOL, to nie posługuj się trybem tekstowym (czyli instrukcją PRINT), lecz binarnym (czyli instrukcją PUT i BPUT).

Prasa kłamie. Ja tak nie wyglądam, a laptopa mam czarnego :P