Nie Pinek, tylko w ostatnim, przed zamknięciem kanału. Ale i tak chyba lepiej znaleźć EOF-a ;)

Hmm, Pinek, jeżeli chcesz dopisać w środek - trza nową funkcję zaimplementować, nie takie głupie. Widzę to tak:
Open #chn,xx,0,"d:dupa.cośtam", gdzie:
#chn - wiadomo
0 - wiadomo
"d:..." - wiadomo
xx - nowy kod operacji: dopisz do pliku
Po takim wywołaniu - od wskazanego bajtu by dokładało w środek (to znaczy: tworzyło bufor do przekopiowania reszty). Kod mógłby wyglądać jakoś tak: (zakładam dopisanie od 5-go bajtu):

 
100 o.#1,xx,0,"d4:nadpisz.dta"
110 put #1,5: . 5 - piąty bajt, od tego miejsca dopisywanie
111 put #1,dane
112 cl.#1

Oczywiście, składnia open z numerem xx przyjmuje, że pierwsze put (jeśli nie chcemy tworzć dodatkowych instrukcji) mówi nam o kolejnym bajcie (lub linii - trza by ustalić) w pliku. Kolejne instrukcje - już standardowe - przesuwają kolejne elementy w środku pliku, aż do napotkania close.
Myślę, że tak by to można było zaimplementować, ale nie znam się na tym, więc musi się wypowiedzieć Draco. Oczywiście, to tylko taka mała sugestia...
Aha, w tym momencie nadal pozostaje nam open z parametrem 12 na nadpisywanie bez przerzucania...
Hmm, jeszcze jedno mi wpadło do głowy - Draco, nie da rady zrobić skróconej wersji open, np w postaci:

o.#1,xx

Dałoby to możliwość do operacji na pliku już otwartym, ale ze zmianą parametru? (np. otwieramy plik do zapisu, zapisuje się coś, trza zmodyfikować, więc zamiast ,8 dajemy ,12 i po sprawie)? xx oznacza tutaj standardowe kody open:
4 - otwarcie do odczytu
8 - do zapisu
12 - zmiana wewnątrz pliku...

Pinek: to nie musi być put, trza tylko określić standard. Może źle napisałem: buforowanie, chodziło raczej o przesunięcie "w locie". Można zamiast przez put ustawić się przez wczytanie iluśtam bajtów (bez sensu), lub przez pojechanie (z pominięciem odczytu - aby zwiększyć prędkość) do któregośtam bajtu w pliku. Put w tym momencie wydało mi się najrozsądniejszym wyjściem, choć przyznaję - nie do końca przemyślanym. Ale jak wiadomo, programy i sugestie rodzą się w bólach, nie mam koncepcji jaką instrukcję (znaną) zastosować. Hmm, może po prostu get?

get #1+bajt_do_którego_się_chcemy_dostać,adres_ulotny,0

Wymagałoby to tylko drobnej modyfikacji instrukcji get, a pozwoliłoby na ustawienie się na porządanym przez nas miejscu, a jednocześnie nie blokowało by pamięcio komputera (w przykładzie pobiera 0 bajtów z pliku, od miejsca, gdzie chcemy coś wstawić). Nie wiem, myślę, że jakoś to można rozwiązać... Pod rozwagę należy wziąć dokładnie ten moment:

 #1+bajt_do_którego_się_chcemy_dostać

, aby był wilk syty, i owca cała - jest to niejako kompilacja dyrektyw GET oraz MOVE, trza by tylko określić możliwość wykorzystania adresowania nie w pamięci komputera, a od znacznika początku pliku z danymi.
A co sądzisz o pomyśle użycia skróconego OPEN? (zmiana tylko atrybutu pliku, bez close)?

Plik jest otwarty jednoczesnie do zapisu i odczytu. Wskaźnik pliku jest tylko jeden dla odczytu i zapisu. W programie odczytałeś 7 linijek (po 2 bajty każda), a potem zapisałeś 3 linie (po 6 znaków = 18 bajtów) i wcięło dokładnie tyle. Linie   8 - 14, to 19 bajtów, czyli o 1 więcej niż zapisałeś ciagiem $0000, $0001, $0002. Ten ostatni bajt to właśnie pusta linia.

Aleś Sikor wymyślił funkcje. Pokaż gdzie coś takiego masz. Należy się cieszyć, że system Atari ma w ogóle podział na pliki binarne i tekstowe. Do takich rzeczy jak wstawianie danych w środek pliku służą: katalog /tmp i pliki *.tmp. :P

Do MM:
Gdzie jest k*.* : twisted : ????????
I gdzie się podział k*.* : mrgreen :

A tak w ogóle, to mamy OT. Miał być MultiBasic, a jest TurboBasic. :P

Problem dotyczy systemu, a nie jakiegokolwiek basica. :P

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

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, tablica miała być jedna. Ale jak masz lepszy pomysł na uniknięcie kopiowania rekordów w sytuacji, kiedy potrzebujesz dostawić jeden w środku, to zamieniam się w słuch. Moim zdaniem inaczej niż za pomocą wskaźników tego się zrobić nie da. Można oczywiście rozłożyć je po całym pliku, tj. żeby każdy rekord miał nagłówek złożony ze wskaźnika do poprzedniego rekordu, wskaźnika do następnego rekordu, ilości danych no i bajtu statusu oczywiście. Tyle, że to zajmuje więcej miejsca i komplikuje trochę poprawianie łańcucha indeksów w przypadku dostawienia czegoś. Ale można i tak, rzecz jasna - wszystko zależy od potrzeb.

No tak, ale najszybsze to to nie jest.

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?

Parser to jest żaden problem.