Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
7th Annual Atari Homebrew Awards Oczywiście nie zabrakło polskich akcentów.
Wyniki FujiCup 2024 Sprawdź, czy były niespodzianki!
Mad Pascal 1.7.2 Optymalizacje, poprawki błędów oraz nowe funkcjonalności.
Tydzień na oddanie głosu w FUJICUP! Głosowanie potrwa tylko do 22 lutego 2025...
TURGEN 9.3.1 Najnowsza wersja oprogramowania TURGEN wprowadza kilka istotnych ulepszeń.
atari.area forum » Posty przez drac030
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.
drac030 napisał/a:Ta wersja OS-u jest prototypowa (nie weszła do produkcji i całe szczęście), ale ta wartość jest taka sama w seryjnym OS-ie XL/XE, zatem chyba można przypuszczać, że planowano komputery z prockiem innym niż NMOS-owe 6502, ale z nim zgodnym.
oczywiscie, atari mogla planowac ale nic z tego nie wyszlo i byl to procesor 6516 ktory nie jest zgodny z 65816 i nie ma z nim nic wspolnego :D
No sam widzisz, że Atari nigdy nie planowało użycia nielegalnych opkodów, planowało za to migrację na wersję rozwojową. W 1984 roku (kiedy XL OS już istniał) takową wersją rozwojową był tylko 65C816. "Komputer Atari serii XL/XE" zatem nie przestaje być komputerem Atari serii XL/XE przez zamontowanie w nim innego procesora niż 6502C. CBDO.
PS. A zwłaszcza nie staje się przez to "emulatorem", w przeciwieństwie do Altirry, której używasz, trzymając 130XE w szafie.
65816 jest procesorem 16-bitowym, jednak Atari z takim procem są jedną z odmian 8-bitowego Atari i jako takie tematycznie należą do tego działu. Zatem jeśli coś, to należy zmienić nazwę (lub definicję) działu. Bo "16/32" to dział ST/TT i odmian, a zatem nie ten temat.
Nie wątpię zresztą, że xxl świetnie o tym wie, tylko po prostu trolluje jak zwykle. I jest regularnie dokarmiany.
atari.area forum » Posty przez drac030
Wygenerowano w 0.126 sekund, wykonano 14 zapytań