
(montaż, ale jak trafny)
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Flob wkracza na Atari ST Platformówka z 8-bitowego Atari zmierza na komputery z serii ST.
Return to Blacktooth dla Atari ST Nowa, izometryczna przygoda w stylu Head Over Heels już dostępna na komputery Atari ST.
VBXETERM 0.12 Nowa wersja emulatora terminala VBXETERM z poprawionym SSH i lepszym wsparciem VT100.
Echa GemTOS 2026 Prace z tegorocznej edycji francuskiego zlotu GemTOS poświęconego komputerom Atari.
BigPEmu 1.22 Nowa wersja emulatora Atari Jaguar od Richa Whitehouse wprowadza wsparcie dla kodów cheat.
atari.area forum » Posty przez drac030

(montaż, ale jak trafny)
TOMS OS jest zgodny praktycznie całkowicie z oryginalnym system operacyjnym XL/XE. Problem może wystąpić jedynie w przypadku programów, które sprawdzają sumę kontrolną OS ROM i od tego uzależniają swoje działanie.
Miałem TOMS OS w dawnych czasach. Wersję bez Turbo 2001 (wydaje mi się, że wersja "bez" jest wcześniejsza), ale z polskimi znakami w ROM-ie. Bardzo sobie chwaliłem. Faktycznie były problemy z uruchamianiem niektórych źle napisanych programów, ale teraz, kiedy wszyscy programiści już mają dostęp do dobrej dokumentacji, takie trudności w przypadku nowych programów nie powinny już występować. No, chyba że ktoś nie umie czytać.
Dobrze, zastanowiłem się też chwilę nad tą dyskusją i doszedłem do wniosku, że dobór sformułowań z mojej strony nie był fortunny. Jeśli poczułeś się urażony, to przepraszam.
Z dokumentacją jest ten problem, że - o ile się w tym orientuję - nie dysponujemy żadną ostateczną wersją, a raczej dokumentacją z różnych stadiów rozwoju tej koncepcji, stąd zdarza się, że poszczególne dataszity sobie czasami przeczą. Tekst w Atariki jest raczej syntezą wszystkich dostępnych danych (w tym analizy kodu XL OS-u) niż bazuje na jakimś konkretnym dokumencie.
Jak mówię, jeśli znajdują się w nim nieścisłości, nie krępuj się z ich wskazaniem. Ewentualna dokumentacja z wymienionych powyżej względów nie jest tu ostateczną instancją.
A ja nie do końca rozumiem, skąd można było powziąć przypuszczenie, że tekst jest oparty na inżynierii wstecznej, skoro zawiera informacje (typu nazw komend), których metodą inżynierii wstecznej zdobyć się nie da.
Info do Atariki zostało wpisane lata temu - konkretnie, ponad 8 lat temu. I owszem, przeważnie to ja to wszystko napisałem, ale nie pamiętam (wybacz, 8 lat), na podstawie jakich źródeł. Dlatego, jeśli widzisz nieścisłości, proszę, byś je wyliczył, zamiast bić pianę.
Dzięki! Ciekawy jestem czy informacje na temat TYPE 2 POLL autor tego artykułu wydobył metodą inżynierii wstecznej, czy opierał się na jakimś dokumencie.
Na pewno przytoczona nazwa "TYPE 2 POLL" świadczy o zastosowaniu czystej inżynierii wstecznej. Jest niewyobrażalne, żeby ją zaczerpnięto z jakiejś dokumentacji.
Jeśli widzisz sprzeczności pomiędzy materiałem Atariki a dokumentacją Atari, nie krępuj się i je wskaż. Na pewno zostanie to wzięte pod uwagę.
Odczep się na chwilę od Duddiego. Ja pytam, gdzie jest wartość dodana wg twojego pomysłu?
Ale przecież można je pobrać "ze strony" (np. z bazy gier na AOL-u), a nie z torrentów. Gdzie jest zatem wartość dodana?
Nie dałem ludziom tych gier za darmo bo nie dotarłem do wszystkich autorów
Czegoś tu nie rozumiem: czy "te gry" nie są dostępne za darmo? Nie można ściągnąć kopii w postaci plików EXE albo ATR z internetu? A jeśli można, na czym miałoby polegać owo "danie ich ludziom za darmo"? Na przepisaniu ich do domeny publicznej de iure, w której i tak są de facto?
drac030 napisał/a:TAB wciśnij.
Fajne ale czy nie lepszym rozwiązaniem było by wklepać cztery znaki, kolejno H,E,L i na końcu P a potem klepnąć ENTER
M,A,N możesz napisać zamiast HELP, gdy chcesz dostać help, ale TAB nie wywołuje żadnych helpów, tylko automatyczne uzupełnianie wpisywanych nazw. Spróbuj napisać DELT i wcisnąć TAB.
To robi: http://atariki.krap.pl/index.php/ACX
się jarałem jak głupi że strzałka w górę daje ostatnią wklepywaną komendę
TAB wciśnij.
Nie znam się, to się wypowiem: podłączyłem kiedyś do Atari XE 12 volt zamiast pięciu. Z tego co pamiętam, szlag trafił układ FREDDIE, ale poza tym wszystko przetrwało.
Acid800.
Zdobyłem napęd M4851A-301M + dane techniczne tejże ściągnięte z netu
Podłączyłem do płytki TOMS720
Napęd nie ten, źle ustawiona stacja przełącznikami? ....
Z doców wynika, że ten napęd jest 40-ścieżkowy. TOMS 720 w ogóle takie obsługuje?
Przemyślałem sprawę i chwilowo zostanę przy przedefiniowaniu BYE. Jeśli wyniknie z tego jakiś problem, wtedy się będzie kombinować dalej. Na definiowanie CP (działającego analogicznie do DIR, czyli tylko w trybie bezpośrednim) szkoda mi miejsca, bo obawiam się, że może go zabraknąć na coś fajniejszego.
Pomysł z różnym działaniem BYE w trybie bezpośrednim i trybie programu wydał mi się zrazu dobry, ale po namyśle wydaje mi się jednak, że wprowadzałoby to zamieszanie.
Jeśli dobrze rozumiem BYE inaczej by działało tylko gdy aktywny jest MEM.SAV. W innym przypadku byłby SELFTEST?
Początkowo tak zrobiłem, ale to powoduje konfuzję, bo żeby wiedzieć, co zrobi BYE, trzeba w danej chwili pamiętać ustawienia MEMSAV. Więc skłaniałbym się raczej ku temu, żeby BYE zawsze wychodziło do DOS-u, i tylko w przypadku aktywnego MEMSAV żeby pomijało jego zapisywanie.
Pytanie brzmi, czy zakłóca to zgodność z AB w sposób, który mógłby komuś sprawić problem, a jeśli tak, to jaki.
Tak czy owak, przy aktywnym MEMSAV potrzebny jest sposób na wyjście z BASIC-a bez zapisywania zawartości pamięci, a przedefiniowanie BYE to jak dotąd najlepsze, co wymyśliłem. Zalety:
1) nie trzeba definiować dodatkowych słów kluczowych
2) jest to proste i skuteczne
3) nie powoduje (chyba?) istotnych problemów ze zgodnością z AB, gdyż jest to tak czy owak wyjście z interpretera bez zachowania zawartości jego pamięci, tyle że nie do Selftestu, a do DOS-u.
Nowych słów kluczowych (typu CRUN) nie będzie, bo kłóci się to z założeniami U-BASIC-a: mianowicie ma być maksymalnie zgodny z Atari BASIC w tym sensie, że program napisany pod U-BASIC-em ma się uruchomić na Atari BASIC-u, a nawet jeśli się nie uruchomi np. z powodu braku pamięci (której U ma więcej), ma wyświetlić komunikat błędu, a nie wykrzaczyć się z powodu napotkania przez Atari BASIC nieznanego sobie tokenu.
Można byłoby wprawdzie dodać CRUN tak jak DIR (że tylko tryb bezpośredni), ale to moim zdaniem byłoby marnotrawstwo miejsca, bo dokładnie to samo osiągamy przez podanie CLOAD/RUN.
Co do PLOT, DRAWTO, LOCATE, te rzeczy są realizowane w OS-ie i BASIC nie ma tu za wiele do gadania. Natomiast POSITION trudno ulepszyć, bo to jest, oprócz odczytu parametrów, LDA/STA/LDA/STA/LDA/STA.
Poza wszystkim, nie ma też specjalnego szału z wolnym miejscem pod ROM-em. W teorii to jest 14k, ale 2k zajmują fonty, a dalsze 2k pakiet FP. Zostaje zatem 10k. Z tego 8k zajmuje sam interpreter, a reszta przeznaczona jest na różne wrappery, DIR, UBI.SAV save/load itp. W tej chwili w obszarze $c000-$cbff mam 26 bajtów wolnego miejsca, a w $e400-$ffff - 1239 bajtów (1,2k).
EDIT: zastanawiam się za to nad modyfikacją działania słowa kluczowego BYE: żeby, zamiast do Selftestu, wychodziło się nim zawsze do DOS-u, tylko bez zapisywania pliku *.SAV. Słowem, takie "cancel" dla ostatnich zmian, jeśli mamy włączone memsav=1. Ktoś widzi jakieś przeciwwskazania?
Nowa wersja U-BASIC-a (1.7) pod adresem jak powyżej. Zmiany:
1) zajmuje 43 bajty pamięci nad MEMLO (w wersji 1.6 to były 52 bajty);
2) dodany plik UBI.CFG, w którym można włączać i wyłączać featury; pod SDX ten plik jest najpierw szukany w $PATH, a potem w bieżącym katalogu - co pozwala na rozdzielenie ustawień na globalne i lokalne;
3) jedną z nich jest zapis zawartości pamięci do pliku UBI.SAV w czasie wykonywania komendy "DOS"; ten plik zostanie wczytany przy następnym uruchomieniu interpretera;
4) SAVE/CSAVE wyciszają dźwięk po użyciu.
A co oznacza napis "Scale!!"?
Bóg jeden raczy wiedzieć :D
To się pokazuje wtedy, kiedy podczas pakowania coś tam mu wychodzi za duże. Zdaje się, że zjawisko dotyczy tylko algorytmu "Squeeze".
Wrzuciłem na stronę nową wersję U-BASIC-a (1.6):
http://drac030.krap.pl/pl-ub-pliki.php
Lista zmian:
1) funkcja RND() przerobiona tak, żeby pozbyć się z niej dzielenia, i żeby lepiej działała z Rapidusem.
2) odczyt wiersza poleceń poprawiony wg tego
http://atariki.krap.pl/index.php/Wiersz ... andard_OSS
3) zniesione ograniczenie wielkości tablic do 32k.
4) procedura obliczająca wielkość tablic numerycznych poprawiona tak, żeby wykrywała ewentualne przepełnienia.
5) dodana instrukcja DIR (dostępna tylko w trybie bezpośrednim).
Tam jest napisane "36007".
Wrzuciłem na stronę poprawiony IDE+BIOS 1.5: http://drac030.krap.pl/pl-kmkjz-pliki.php
Błąd powodował, że nie działał APT FDISK (przez 3 tygodnie nikt tego nie zgłosił :P).
Poprawkę wprowadziłem na gotowym pliku binarnym, bo błędny był tylko 1 bajt, więc numer wersji w środku się nie zmienił. Zmieniła się za to długość wynikowego pliku *.COM, bo przy okazji podmieniłem też flaszer na nowszą wersję.
drac030 napisał/a:Co pokazuje polecenie MEM /X?
3072 KB linear RAM (48 segments)
Wyłącz linear i sprawdź, czy problem się powtarza. Jeśli nie - załaduj sobie jednak betę.
DEVICE SPARTA BANKED
I przeczytaj dokładniej instrukcję :P
EDIT: sorry, zła odpowiedź. To jest problemem:
Top: $80FF ($A0FF),$7FFF
Free: 27615 (56007),2818
Niecałe 27k wolnego RAM-u to faktycznie za mało, a ARC nie dorósł jeszcze do wykorzystania extu. Musisz się przełączyć w 40 kolumn, wtedy będzie działał.
Druga liczba we "Free" (ta w nawiasie) na pewno jest taka?
atari.area forum » Posty przez drac030
Wygenerowano w 0.137 sekund, wykonano 20 zapytań