A propos http://www.atariage.com/forums/index.ph ... pic=130284

A ja (tak dla podrażdienia rozgowora) miałem ciekawy problem z franny. Mianowicie franny, jeśli plik kopiowany na ATR zawierał bajt o wartości 13 ($0D), robiło z jego - tego pliku - zawartości w zasadzie bigos. Czy ktoś się spotkał z takim zjawiskiem?

Sensacja, poprawili to w końcu: http://www.wdesignc.com/wdc/documentation/w65c816s.pdf

Manual ma datę z przedwczoraj. Znaczy, nie wymarli do końca, coś się tam życia tli :)

mikey: wypomnij mi, ilekroć zarzucę komuś, że nie zajrzał po coś do atariki :) Thx

Żaden zwykły DOS na Atari - oprócz SpartaDOS-u - nie ma seeka, czyli nie pozwala "czytać pliku od określonego miejsca". Da się to obejść, ale metodą dość upierdliwego indeksowania. Przekopiujesz plik w inne miejsce nawet na ten sam dysk, i trzeba go przeindeksować.

Sparta to ma, nie trzeba indeksowania. To jedna z jej przewag. No ale czy te bazodanowe funkcje muszą być zaszyte w DOS-ie? Nie, możesz, jeśli chcesz, napisać aplikację, któa stworzy bazę danych i będzie ją obrabiać wedle woli. Nawet coś takiego miało być dla SDX, ale zwiędło. Niemniej, jesli dBase III może być pod CP/M i działać, to dlaczego nie na Atari.

Ponieważ od roku ponad mój atarak jest nieczynny, więc nie mam specjalnej motywacji. Oczywiście doskonale rozumiem, że skończenie się tablicy symboli to jest jedyne, co może powstrzymać TDC przed napisaniem programu na Atari.

PS. Może adiministracja przeniesie ten wątek do bałaganu?

Różne rzeczy nazywają się tak samo w różnych miejscach, np. seek dla DOS-u to zupełnie co innego niż dla kontrolera flopa.

create oidp tworzy plik na dysku i zwraca uchwyt 'write-only', no czyli po naszemu to jest OPEN #n,8,0,"D:nazwa" (i to zawsze było, nie?)

select usypia program do momentu, kiedy w którymś z podanych plików (a raczej ich uchwytów) nie pojawią się dane (bez mtasku sens wątpliwy).

Pomysły są zawsze mile widziane, ale na temat SDX to może nie w tym wątku? Bo się oftop robi.

No w sumie, ... sektory 512-bajtowe dają kopa jeśli chodzi o prędkość odczytu na IDEa, ale MyDOS i tak jest tak wolny, że chyba niewiele by mu to pomogło :) Poza tym bufory trzeba byłoby powiększyć, dzięki czemu MEMLO pewnie sięgnęłoby stratosfery.

@dely: sugerujesz, że pinokio nie umie skonfigurować SDX? Bo faktycznie, kompoty w Głuchołazach puszczał spod MyDOS-a, pamiętam mój sprzeciw na ten widok, któremu chyba nawet dałem wyraz ;)

Nie czaję... a co z plikami krótszymi niż 6 sektorów?

Co do koduj - to nie jest pomysł na kodowanie, tylko na temat na forum. :P Jak wiadomo, ja się zajmuję SpartaDOS-em, w MyDOS-ie grzebać nie mam zamiaru, przypuszczalnie i tak nic z tego, o czym tu mowa, nie dałoby się zaimplementować z prostego powodu - MyDOS tak zmodyfikowany zająłby za dużo pamięci. Jeszcze oryginał (post 1) ma minimum zmian, ale pewnie wymagałoby dodania procedury oddzielnie wyszukującej parzyste i nieparzyste sektory, no i na tym by pewnie wszystko legło. Ale kto wie, może taki np. macgyver się zainspiruje ;D

Mamy 16-bitowy link plus niezerowy "znacznik" w "normalnym" sektorze, a w ostatnim sektorze "znacznik" = 0, a zamiast linku mamy wypełnienie, tak? To dlaczego znacznik ma zajmować cały bajt? Może zajmować 1 bit chyba. Link można wydłużyć do 23 bitów, ale obiekcja jest w mocy.

Gdzieś kiedyś widziałem doce do FS MyDOS-a, ale gdybym je miał pod ręką, jak grzebię w atariki, to ten artykuł by już dawno powstał...

To jest w atariki, kliknij na "Formaty systemów plików" na str. głównej.

EDIT: Jeszcze tylko dodam, że normalny program kompletnie nie potrzebuje wiedzieć, co to są bity statusu i czy istnieją. Do dostępu do dysku (np. zapisu albo odczytu plików) korzystasz z CIO (zob. atariki, hasło CIO na str. głównej). Zapenia to niezależność od formatu dysku, pojemności, wielkości sektora itede.