No może. Opieram się na tym, co pamiętam z działania Fcreate() w GEMDOS-ie ST, ale niekoniecznie muszę pamiętać dobrze. Wszystko jest do zweryfikowania w źródłach MiNT-a, oidp są to dwie oddzielne funkcje w sumie, jedna Fcreate(), a druga Fopen() z odpowiednimi flagami. Tak czy owak, ponieważ pod SDX tworzenie plików załatwia zwykłe OPEN, nie widzę potrzeby...

create już jest (zawsze było), select natomiast, o ile pamiętam do czego służy, to nie bardzo sobie wyobrażam w systemie, w którym nie ma multitaskingu.

@miker: no, to powinien sobie wymienić na nowszą wersję, mieliśmy gotową betę 4.42, były trzy dni na przetestowanie i upewnienie się, czy wszystko działa.

Bajt niekoniecznie (gdy sektor już był pełny), ale link owszem. Więc w sumie obiekcja nie jest taka ważna, jak mi się wydawało na początku.

A z licznikiem inne coś miałem na myśli: jak odróżniać ostatni sektor pliku od każdego innego. Liczba sektorów zajmowanych przez plik jest w directory, wystarczy, żeby procedura odczytująca pobrała ją do pamięci i przy sekwencyjnym odczycie kolejno zmniejszała. Przy dojściu do 1 wiadomo, że jesteśmy w ostatnim sektorze i żadne znaczniki nie są potrzebne.

Dlaczego niby ja "mam" to wiedzieć?

ALe przy 512-bajtowym sektorze ostatni bajt = $00 może równie dobrze oznaczać $0100. Raczej, jesli się nie znajdą obiekcje (których nie umiem wymyślić, ale wstałem rano ...), stawiałbym na to, co napisałem w EDIT w poście nr 9 - licznik sektorów (oddzielny dla każdego pliku) co prawda wydłuża DOS, ale to w tym wypadku i tak jest nieuchronne. A pojemność dysku zwiększa się w nieskończoność (16777216 sektorów po 16777216 bajtów :])

EDIT: obiekcja (dotycząca chyba wszystkich propozycji): w trybie odczyt/zapis (12) albo dopisywania (9), gdy plik wypełnia całkowitą liczbę sektorów, przed dodaniem nowego trzeba zmodyfikować zawartość "poprzednio ostatniego" sektora. To chyba trochę komplikuje.

Naturalnie, można. Nie wiem tylko, czy w directory MyDOS-a znajdzie się wolny bit. To jest klon DOS-a 2.5, ale ma podkatalogi. Jednak, przy odrobinie szczęścia, zajmuje to tylko jeden bit (czyli dwa są wolne).

EDIT: albo jeszcze inaczej: zliczamy sektory podczas odczytu, i w ostatnim link ma inne znaczenie, tzn. mamy 24 bity wypełnienia, a w pozostałych sektorach są 24 bity linku. Ktoś zna jakieś obiekcje?

@xxl: odpowiedź brzmi: nie każdy plik na dysku jest plikiem binarnym. Ergo, twierdzenie zawarte w pkt. 2 twojego posta jest fałszywe.

@epi: hmm, ale załóżmy, że mamy mieć wypełnienie 509. 509*2 = 1018, a to jest 3FA hex, jednak mamy tylko 9 bitów do zapisania wartości wypełnienia (8 w linku plus LSb nru sektora), co nam obcina najstarszy bit, więc wychodzi nam 1FA hex czyli 506 w sektorze parzystym i 507 w nieparzystym. Czyi źle, bo ma być 509. Nie wiem, czy dobrze liczę ...

@pin: ja bym dyskwalifikował za niechodzenie pod SDX :) Dlaczego polskie dema mają chodzić pod całkowicie amerykańskim MyDOS-em albo całkowicie niemieckim DOS-em II/+D, a pod w większości już polską Spartą X nie? ;)

Owszem, jest to napisane w FM.

PS. W dodatku w najoczywistszym miejscu z mozliwych: przy opisie błędu nr $A1 (aka 161).

Ok, to dozo w Głuchołazach :)

No właśnie, co z tym "przyszłym rdzeniem"?

Mnie sie osobiście pomysł xxl-a nie podoba, może niech to juz będzie tylko to, co miało być, a koprocesor, jak ma być, to niech będzie w oddzielnym układzie. Bo obawiam się, że od takich rzeczy może w FPGA zabraknąć miejsca na to, co on ma w istocie robić, tzn. na SuperGTIA. No i wiadomo, trochę wolnego musi zostac na ewentualne późniejsze poprawki/rozszerzenia.

Odpowiedź pewnie jest taka sama, jak na "dlaczego podczas konstruowania nowych, lepszych 8-bitowych Atari używano ciągle tego samego chipsetu sprzed 7 lat": ze skąpstwa lub pospiechu. Stawiam na to pierwsze, wiadomo że taka firma prędzej kupi jacht dla prezesa albo nowy wieżowiec pełen sekretarek niż przeznaczy kasę na unowocześnianie produktu, który "i tak jest dobry, a userzy są zachwyceni" :)