Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Galactic Panic - nowa przygodówka na ST Darmowa gra point and click na Atari ST - ponad 100 ekranów przygody.
Nowa wersja ARIFE Tool od PVBest73 Uaktualniono uniwersalne narzędzie do analizy obrazów ROM i dysków Atari
Echa Sommarhack 2025 Podczas szwedzkiego party Sommarhack zaprezentowano kilkadziesiąt produkcji,
MadPascal 1.7.3 już dostępny Nowa wersja kompilatora MadPascal przynosi poprawki i optymalizacje
Echa Lost Party 2025 Wyniki, zapis wideo oraz stuff.
atari.area forum » Posty przez drac030
Moja lista. Są to programy, które nie chcą działać (wcale albo działają nieprawidłowo) z plików ATR znajdujących się na partycji twardego dysku i otwieranych przez loader binarny IDE+:
Gry:
1) Koronis Rift
2) Samobójcy
Dema:
3) Bitter Reality
4) Cool Emotion
5) Endless Dream
6) Ergo Bibamus (ale istnieje wersja plikowa, która chodzi)
7) Joyride #1
8) Joyride #2
9) Muppet Movie
10) Overmind (oprócz dysku nr 3)
Inne:
11) Superdos 4.3
Moim zdaniem w Ultimate, bo to bez sensu, żeby SDX obliczała i ustawiała w zegarku bezużyteczną wartość, na zrobienie czego marnuje się RAM, mimo że równie dobrze można byłoby to obliczyć w menu U1MB, czyli jedynym miejscu, gdzie ta wartość jest w ogóle wykorzystywana do czegokolwiek.
Ale stery od zegarka to nie mój resort, jak trubu z candlem zrobią, tak będzie.
Obecny sterownik zegara (ULTIME.SYS) ma już procedurę do obliczania dnia tygodnia i wpisuje go do wspomnianego rejestru.
No i po co to mówisz, kiedy ja już go namówiłem do zrobienia tego w menu U1MB :P
1) date.com i td.com nie mają ze sobą nic wspólnego, to są dwa różne programy (typu aplikacyjnego) korzystające ze sterownika zegara.
2) nie da się "tego" "dodać do API", bo wymagałoby to przerobienia wszystkiego, co ma cokolwiek wspólnego z datą w SDX. Tablice przeznaczone na czas i datę mają 3 bajty na jedno, 3 na drugie, miejsca na dzień tygodnia w tych strukturach brak, zatem nawet gdyby program (typu date.com) nawet wyliczył dzień tygodnia, nie ma tego jak przekazać do drivera.
3) jak mówię, mógłby sobie to wewnętrznie wyliczyć driver, ale po co, skoro kosztowałoby to trochę RAM-u, który można prosto zaoszczędzić, umieszczając stosowny kod w ROM-ie U1MB (w menu, które zamiast czytać random śmieci z rejestru dnia tygodnia zegara, mogłoby dość prosto obliczyć, jaki on powinien być).
który z daty którą i tak już policzył
Driver nie liczy żadnych dat, on zapisuje to, co dostał od wywołującego go programu. W danych tych nie ma dnia tygodnia (ubolewam, ale tak po prostu jest).
nie jest dla mnie ważne, czy wyliczeń tych dokonuje TD, ultime.sys, czy też polecenie DATE, ważne jest, że ten kod juz istnieje, co czyni Twój argument pustym
Nie jest ważne, a powinno, bo TD jest programem aplikacyjnym, i to on sobie wylicza dzień tygodnia, w celu wyświetlenia go na ekranie. Taki equalizer.
Natomiast driver ultime.sys (ani DATE ani nic w ogóle) tego wyliczenia nie robi, bo czegoś takiego jak "dzień tygodnia" w ogóle nie ma w API. Zatem jednak lepiej, żebyś wyliczał tę wartość przed jej wyświetleniem w menu U1MB, bo jak widać, rejestr co prawda jest, ale nigdy nie wiadomo, czy zawiera prawidłową wartość.
W IDE+ jest dokładnie to samo, to znaczy, w zegarku jest rejestr dnia tygodnia, ale co z tego, skoro zegarek ma w nosie, czy ta wartość jest prawidłowa dla podanej daty. Dlatego też BIOS IDE-Plusa wylicza tę wartość na piechotę olewając rejestr, który, skoro działa tak, jak działa, psu na buty jest potrzebny.
Gdybyście obaj z Lotharkiem wypowiadali się precyzyjnie, nie tracilibyśmy czasu na jałowe dyskusje. Oto moja hipoteza na temat, o co tu chodzi:
1) U1MB na swoim menu (Help+Reset) pokazuje zły dzień tygodnia (aka "jeden dzień do tyłu"), jeśli datę przestawi się spod SDX.
2) jest tak, bo zapis przez driver ultime.sys zapisuje tylko to, co jest podane, to znaczy czas i datę, natomiast dzien tygodnia zostaje bez zmian
3) ty, candle, chcesz, żeby ultime.sys, będąc rezydentem zajmującym pamięć RAM, urósł dodatkowo o kod, który z podanej daty wyliczy dzień tygodnia i zapisze go do tego rejestru
4) a jest tak, bo tegoż kodu (wyliczającego dzień tygodnia) nie chce ci się umieścić w ROM-ie, mimo że masz tam na niego od pyty miejsca. :P
Dobrze rozumiem?
No i?
SC 0.8.3 - jeśli po restarcie programu w otwartych oknach, lub pojedynczym oknie commandera po ponownym uruchomieniu nie zastaniemy takich samych ścieżek (np. odmontowane po restarcie SIO, lub wykasowany aktywny katalog i wyjście z SC bez zapisu konfiguracji, np. poprzez wyłączenie zasilania) to otrzymujemy błąd 150 (path n.f.) który zapętla program.
Faktycznie. Ale to występuje znowu tylko w obecności CON.SYS w pamięci, czyli to pewnie jest ten sam problem, co powyżej.
Cześć
Gdyby ktoś miał ochotę, to dzisiaj od 18.00 będzie mikro-sztabik w Dekancie (ul. Marszałkowska 55/73). Propozycja dla tych, co nie mogą się zjawić w weekend na Ochocie. Wiem, że trochę późno na ogłoszenia, ale może komuś się uda.
Tia, coś tam jest nie tak - w CON.SYS znaczy - zajrzę do tego niebawem.
Muszę nadmienić, że pomysł o tyle nie jest mój, że był poniekąd inspirowany czymś, co jest znane na Atari ST/TT/Falcon, mianowicie niejakim Cookie Jarem. Jest to kawałek pamięci (o rozmiarze deklarowanym w minimalnym rozmiarze przez TOS, ale możliwym do zmiany przez użytkownika) należący do BIOS-u, który ma za zadanie zasygnalizować, jakie zasoby sprzętowe wykrył tenże BIOS oraz ładowane podczas startu systemu programy.
Cookie Jar zawiera iks wpisów po 8 bajtów. Pierwsze 4 bajty to identyfikator zasobu, następne 4 to wartość zależna od zasobu, definiująca jego jakość. Np. $5F, $43, $50, $55, $00, $00, $00, $1E oznacza: 1) pierwsze cztery bajty to znaki ASCII "_CPU", 2) drugie cztery bajty to wartość sygnalizująca z czym mamy do czynienia w danej dziedzinie, przykład mówi $0000001E = $1E = 30, znaczy, CPU = 68030.
Oczywistą korzyścią jest to, że programy nie muszą (jakkolwiek oczywiście mogą) wykrywać sprzętu na własną rękę, wystarczy krótka procedurka zaglądająca do Cookie Jaru. Oczywistą korzyścią następnego rzędu jest to, że przez ingerencję w Cookie Jar można (jeśli zachodzi potrzeba) spowodować wyłączenie pewnych zasobów sprzętowych, nawet jeśli fizycznie są dostępne - np. autor programu może być ciekaw, jak się zachowa jego dzieło bez dodatkowej pamięci, bez stereo, bez VBXE itp.
Tablica danych dostępna dla takiego urządzenia @: może być oczywiście uzupełniana/modyfikowana przez nierezydenty ładowane przy starcie systemu. Np. wielkość i typ pamięci dodatkowej raczej nie zmieni się bez zimnego startu, zatem można załadować kawałek nierezydentnego programu, który przy starcie systemu przetestuje pamięć i zapisze odpowiednie wartości w tablicy, a potem zakończy się nie pozostawiając innych śladów.
na screenach widac ze "planowany" rozmiar to 5736 sektorow. wynikowy plik wypluty przez plugin na screenie ma 1468022 bajtow.
plik powinien miec 1468048 bajty przy 5633 256cio bajtowych sektorach + 3 128 bajtowe + 16 bajtow naglowka, lub 1468432 przy 5736 256cio bajtowych sektorach + 16 bajtow naglowka.wartosc ze screena nie pasuje do obu wyliczen.
5733 * 256 + 384 = 1468032 - to bez nagłówka. Tymczasem gotowy plik z nagłówkiem ma 1468022 bajty. Plugin odejmuje 10 bajtów zamiast dodać $10?
Strona www zapewne.
Możesz tworzyć tak jak tworzysz, ale potem weź dowolny DOS i zrób soft format. Pod SDX FORMAT->Build directory. Pod MyDOS-em I, nr dysku/N
Jest też możliwość, że ATR jest zły, mgliście mi się kojarzy, że A800Win robi złe ATR-y. W takim układzie nie poradzę. Ja sam puste ATR-y robię programem sio2bsd, a katalogi zapisuję z Atari, spod SpartaDOS X.
mono jest taki ścichapęk... ;) kompletne przeciwieństwo niektórych tutejszych lanserów, co to wiele ryczą, ale niewiele mleka dają (a jak już, to wodniste).
Może ATR jest zbyt pusty, tzn. nie ma na nim zapisanej struktury VTOC. Jeśli VTOC zawiera same zera, to może to wyglądać tak, jakby wszystkie sektory były zajęte.
Mam na myśli próby Rybagsa w celu uruchomienia trybu pavrosa, patrz link do AAge, który podał wyżej Candle, post nr 8.
Ja postanowiłem zgłębić temat i przy okazji odkryłem, że mozna też opóźniać CSYNC. Uważam, że takie feature'y należy zbadać, udokumentować i zaprezentować w kilku prostych demach. Nawet jeśli pożytek z nich będzie niewielki. Wiadomo, że takich trybów opartych na "rozgrzanym" GTIA nie można użyć w prawdziwych demach, grach czy programach użytkowych i pozostaną one raczej ciekawostką. Jakkolwiek, można robić w tym grafiki i filmiki.
Myślę, ze problemem jednak pozostaje owa "suszarka", oraz - jak póki co wygląda - to, że nawet mimo silnego nagrzania efekt na niektórych komputerach nie występuje (casus Rybagsa - a ja tylko czekam, aż się tu dowiemy, że takie Atari to nie Atari).
Ale jeśli jest to kwestia opóźnienia CSYNC, to może zamiast tak kombinować, wystarczyłoby zbudować układ opóźniający, który można byłoby na żądanie włączać i wyłączać jakimś rejestrem?
toolkit.atr ma sektory po 256 bajtów (a pierwsze trzy po 128).
Size DISC= 1468000b -> 1433.59Kb -> 1.40MB Size ATR= 1468016b -> 1433.61Kb -> 1.40MB ... Sector: -size= 256b -all= 5735 -max= 5721
5735 sektorów po 256 bajtów to jest 1468160 bajtów, a nie 1468000.
5721 sektorów po 256 bajtów to jest 1464576 bajtów, a nie 1468000.
Jeśli założyć, że pierwsze trzy sektory mają po 128 bajtów, to wciąż wielkości wynoszą odpowiednio 1467776 i 1464192 (a nie 1468000).
Żadna tam mega-tajemnica, sterownik powstał gdzieś w marcu i się ukaże w Toolkicie razem z SDX 4.46.
Candle, czy słusznie przypuszczam, że obiekt przedstawiony na fotografii to są cztery Soundboardy, a nie jeden taki duży?
Przecież obok domu masz Tesco.
Wg dostępnych mi danych Atariki powstało 7 grudnia 2004 - dokładnie 8 lat temu. Proponuję wznieść toast.
Gdyby to miało się ukazać w druku, protestuję - w imieniu własnym oraz komitetu powiatowego d/s Atari - przeciw użyciu logo zarówno SDX jak i Atari, jeśli mają być tak słabej jakości.
atari.area forum » Posty przez drac030
Wygenerowano w 0.136 sekund, wykonano 15 zapytań