3,951

(66 odpowiedzi, napisanych Fabryka - 8bit)

Pin napisał/a:

Draco - a oto i przykładzik nieprawidłowego działania nadpisywania danych w pliku:

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

3,952

(21 odpowiedzi, napisanych Bałagan)

Ale nie dwa lata. Prasa kłamie :P

3,953

(21 odpowiedzi, napisanych Bałagan)

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

3,954

(21 odpowiedzi, napisanych Bałagan)

Artykuł ma ze sceną małego Atari wspólne to, że "Gazeta Wyborcza" za Chiny Ludowe takiego artykułu o tej scenie nie opublikuje :P

3,955

(20 odpowiedzi, napisanych Sprzęt - 16/32bit)

Sukkor_benoth napisał/a:

To po co to trzymasz jak nie włączasz ;)

Bo mi się szkoda rozstać.

3,956

(20 odpowiedzi, napisanych Sprzęt - 16/32bit)

Ma SCSI. Ja mam TT, ale nie powiem, żebym ten komputer włączał ... :/

3,957

(21 odpowiedzi, napisanych Bałagan)

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.

3,958

(20 odpowiedzi, napisanych Sprzęt - 16/32bit)

Ciekawe, ile sztuk TT w ogóle sprzedano.

3,959

(15 odpowiedzi, napisanych Sprzęt - 8bit)

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

3,960

(20 odpowiedzi, napisanych Sprzęt - 16/32bit)

Tylko czemu ci inżynierowie pracowali nad TT tak długo (zaczęli w 1986 roku) ... ?

3,961

(27 odpowiedzi, napisanych Emulacja - 8bit)

nosty napisał/a:

Real Atari na kibel nie zabierzesz a laptopka z emulatorem jak najbardziej :D

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.

3,962

(27 odpowiedzi, napisanych Emulacja - 8bit)

OO nigdy nie kompilowałem. Ale skoro trwa to tylko 6 godzin, to może spróbuję. KDE kompiluje się dłużej (chyba coś ok. 12 godzin na p4 3 GHz, ale nie mierzyłem czasu dokladnie), a robiłem to już parę razy ...

3,963

(53 odpowiedzi, napisanych Quast Rules)

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

3,964

(9 odpowiedzi, napisanych Bałagan)

Jeśli to ten sam, co Bill Kendrick czyli William Kendrick, to do tej pory występuje taki na comp.sys.atari.8bit.

3,965

(27 odpowiedzi, napisanych Emulacja - 8bit)

macgyver napisał/a:

na Atari wszystko kompiluje się równie szybko jak na cross-asemblerze ;) i nie ma ograniczeń edytora ;)

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ł :/

3,966

(53 odpowiedzi, napisanych Quast Rules)

macgyver napisał/a:

są ludzie, którzy "są twardzi"

Najciekawsze, że to wcale nie wymaga aż takiego samozaparcia. Wymaga jednak używania odpowiednich narzędzi. Jak się ktoś trzyma QA jak pijany płotu, to nie dziwne, że mu na Atari kodować niewygodnie :P

3,967

(20 odpowiedzi, napisanych Sprzęt - 16/32bit)

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

3,968

(20 odpowiedzi, napisanych Sprzęt - 16/32bit)

Ta płytka to jest właśnie 16 MB TT RAM-u.

Zgodność w dół jest taka, że programy generalnie chodzą, ale dema i gry nie. Powodów jest multum, przede wszystkim procesor 68030 i jego cache, ale niektóre programy nie lubią też TT RAM-u.

3,969

(27 odpowiedzi, napisanych Emulacja - 8bit)

asal napisał/a:

AMD Athlon 1700+, 768GB RAM

No nieźle. Nie wiedziałem, że Athlony potrafią tyle zaadresować ;) :P

3,970

(19 odpowiedzi, napisanych Sprzęt - 8bit)

Pin napisał/a:

... i jak się okazało - sprawa jednak poległa początkowo na etapie ZASILANIA

Amen :)

3,971

(19 odpowiedzi, napisanych Sprzęt - 8bit)

Pin napisał/a:

hmmm - bazuje generalnie na własnych doświadczeniach, oraz wypowiedzi Krapa i Pasia.

Jak odzyskam panowanie nad atarynką (czytaj: jak wymienię dysk na nowy, oraz jak mi się uda odzyskać dane ze starego), wtedy siądę i napiszę jakiś konkretny program do diagnostyki dysku i interfejsu.

Szkoda, że nie wpadłem na to od razu, ale też teraz są lepsze możliwości testowania :)

3,972

(19 odpowiedzi, napisanych Sprzęt - 8bit)

Pin napisał/a:

:) - z czego pamiętam kończy się to oknem o zawartości "checking..." - i albo tak sobie wisi; po ESC wychodząc do dosa, albo (w jednym przypadku) FDISK się uruchomił, lecz nie napisał niczego w dziale "Controller model" a liczba cyl, heads, sect, total = 0.

To "Checking" ma dość krótki timeout, więc jeśli widnieje na ekranie w nieskończoność, to znaczy, że coś ci się z komputerem lub ewentualnie interfejsem IDE krzaczy. Powinien albo się FDISK normalnie uruchomić albo powiedzieć ci, że nic z tego i dopiero wtedy wyjść do DOS-a (na Esc).

Jeśli się uruchomił, ale nic nie wyświetlił, to znaczy, że przeczytał ID, a w nim same zera. To jest objaw problemów elektrycznych pomiędzy komputerem a interfejsem albo pomiędzy interfejsem a dyskiem (kartą). Może karta coś za bardzo obciąża, albo coś zwiera, albo czegoś nie zwiera, nie wiem, w każdym razie objawy wskazują raczej na hard.

3,973

(19 odpowiedzi, napisanych Sprzęt - 8bit)

jest to sprawką IDE biosu

Raczej mało prawdopodobne.

PS. "założenie karty 256MB ... kończy się niczym", to znaczy czym właściwie się kończy? FDISK wraca ci do DOS-u bez słowa?

3,974

(9 odpowiedzi, napisanych Sprzęt - 8bit)

nosty, Sikor ma rację, w punkcie pierwszym opisujesz działanie carta SpartaDOS X.

3,975

(66 odpowiedzi, napisanych Fabryka - 8bit)

Eeee? A może jakiś program przykładowy?