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

Bo mi się szkoda rozstać.

To że ten pan tam dużo pił ("wody, soku, coli i piwa"). Oraz, że to ogólnie Chiny, a większość sceny Atari ma komputery z beznadziejnymi, chińskimi klawiaturami.

Wniosek? Firma Commodore lepiej by na tym wyszła, gdyby poświęciła się całkowicie produkcji monitorów :)

Własnie dlatego ja bym chętnie miał przenośną atarynkę, zasilaną z baterii i mającą monitor LCD. Notebooka mam, i mam na nim emulator, ale to nie to samo.

Prócz tego, że jak już ustaliliśmy, vim nie ma skoków do miejsca definicji etykiety :P I gdzie ty widzisz powyżej swojego postu choćby słowo o MAE? :) Fakt, że jest lepszy od QA, ale przecież trudno chyba znaleźć gorszy (ok, są jakieś syfy napisane w BASIC-u ...)

Macgyver, przyznam ci rację, jak w trakcie pisania programu osiągniesz koniec możliwości edytora (i kompilatora) MAE. Do tej pory nie gadaj o ograniczeniach, które cię zmuszają do przejścia na pieca. :P Niestety, są tacy, którym łatwiej się jest rozstać z Atari, niż z mającym faktycznie kupę irytujących ograniczeń QA. :(

Co do szybkości kompilacji, to nie trwa tak długo (oczywiście na MAE albo MAC/65), żeby rwać włosy z głowy, a setki z portfela i lecieć kupować pieca. Ja tam 30 sekund albo minutę mogę poczekać i nie jest to żadne poświęcenie (czekało się po 3 godziny na skompilowanie programu na Falconie, więc mam - powiedzmy - wprawę).

A utracić źrodła w wyniku zawieszenia się komputera nie udało mi się chyba nigdy. Oczywiście może się to zdarzyć, jak działasz na ramdysku. Od tego jest twardy dysk. Może on paść, ale pecetowy tak samo: jakbym zaufał Toshibie, którą mam w notebooku, jako miejscu do przechowywania źrodeł lepszemu niż dyskietka 5,25 cala, to ładnie bym dzisiaj wyglądał :/

Od biedy jest jakiś emulator blittera na TT, jeśli się ktoś uprze.