Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
TURGEN 9.3.0 Kolejna wersja multiplatformowego narzędzia do zarządzania obrazami taśm.
SV 2024 WE - program imprezy Już za tydzień odbędzie się zimowa edycja Silly Venture
Nowa obudowa dla 800XL - zostało 36 dni Niewiele ponad miesiąc do końca kampanii.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
atari.area forum » Posty przez trub
Się robi :D
Aaa do której grupy byś się zaliczył ? :twisted:
Źródła wziął ode mnie jad, miał wybadać sprawę.
Na pocieszenie załączam binarkę QA wersja 0.13 dla sadomasochistów i kolekcjonerów ;) Mam też 0.37.
Z małpą nie jest tak źle, automaty wyszukujące emaile zgłupieją ;)
Cyfra też może być, chociaż zero myli się z O.
Dla dodatkowej pewności mógłbyś wymusić jakieś specjalne Auxy.
Zdaje się, że Neotracker też nie działa. Czyżby Epi używał bebechów OSa ?
Wyguglałem tekst zachęcający do użycia Q:, o tutaj. Może więc zamiast literki użyć jakiegoś krzaka ? Wtedy prawdopodobieństwo konfliktu będzie mniejsze.
Czy będzie zawsze tylko Querowanie? Może w przyszłości jakieś Setowanie ? ;)
Na JBW nie napiszę złego słowa, bo to u nas legenda :rolleyes: Wolę myśleć, że te nielegale wzięły się z braku literatury. Tutaj do Galicji wszystko dociera z opóźnieniem ;) a JBW zaczynał jeszcze na początku lat 80-tych.
Wywoływanie funkcji OSa przez XIO jest fajne. Z literką może być problem, więc może jakiś dodatkowy wyróżnik, np. wirtualny numer IOCB np. 8 ? :D
Niemanie klika klawiatury bym przeżył ;), bo i tak wyłączam przy starcie kompa. Ale funkcje możesz dodać, choć bardziej wolałbym szybkie SIO, albo bootowanie z dowolnego dysku (o ile miejsca zostanie :D).
Wrzuciłem w wcześniejszym poście poprawioną wersję ED26.COM - pod SDX nie działało poprawnie Load/Save. Teraz powinno być lepiej.
Wyciąg z doca w SDXPACK: :twisted:
EYE COM Written by JBW, modified by KMK.
You like this package? simply send? ? 5 USD or 12 new polish zloties...
QA u mnie nie działa. Objawy jakby coś było z folią klawiatury ;)
Po kiego grzyba ? Nie wiem, ale po dalszej analizie widzę jeszcze kilka dziwnych rzeczy w ED.COM do poprawienia.
Szkoda, że nie mam źródeł, wtedy można i klika mieć i jingle BELL ;)
AS to podręczny dissasembler. Też coś nie tak z klawiaturą pod 816osem.
Zdaje się, że kiedyś coś mieszałeś z EYE. Może masz źródła?
Draco narzeka, więc może ja się odezwę :D
Z tymi programami JBW, że nie działają to masz rację. Np. ED, AS, EYE. Trochę szkoda, bo fajne :(
Np. w ED.COM są nielegalne skoki do procedur KEYCLICK, BELL i tablicy KEYDEF. Wywaliłem dwa pierwsze skoki, a do KEYDEFa użyłem wskaźnika $79 na stronie zerowej, jak Pan Bóg przykazał :twisted: i ruszyło. Szkoda, że bez efektów dźwiękowych ;)
Testuję dalej...
Coś nie działało load/save, wgrałem poprawioną wersję.
Dzięki :D, już wgrywam nową wersję na flasha.
Czy mógłbyś napisać (tu albo tam) jak oficjalnie rozpoznawać Twoją wersję OSa ? Chodzi mi o '816 support ;)
draco, kiedy nowy release?
Zabieram się za eproma, a wgrałbym najnowszą wersję, bo już sporo zmian...
jak odróżnić 4.20 od 4.22
W $701 jest $42 => SDX 4.22
W $701 jest $40 => SDX 4.20... albo 4.21. A 4.21 ma przesunięte adresy jak 4.22 :(
Jak ktoś używa SDX 4.21, to niech się odezwie :!:;)
O adresach w QE napisałem Ci na PM.
trub wie... (chyba) :D
Tekścik o sweet16, to z RAMDISK.SYS. Na początku sprawdza standardowym testem (SED, $99+$1 itd.), czy jest 65816. Jeżeli jest to idzie dalej, jeżeli nie ma to wyświetla tekścik i... idzie dalej. Reszta kodu jest taka sama dla obu proców (oprócz modyfikacji tekstów ICT na FTE itp.).
Chodzi chyba o podniesienie na duchu tych, ktorzy za ciężkie pieniądze kupili wspomnianą płytkę, bo wszystkim innym wyświetla się wspomniany tekst. Jak kogoś ze Spartą 4.22 to wkurza, bo nie ma proca 16-bit, może se spokojnie zamienić na stary RAMDISK.SYS 8)
Główną zaletą wersji 4.22 jest wg mnie SIO2.SYS. Umożliwia używanie procedur SIO systemu operacyjnego, a nie Sparty. Jak ktoś ma QMEGa 4, to OS załatwia wszystkie tryby (nie mylić z truby ;)) szybkiej transmisji. I mamy bardzo niskie memlo, bo sterowniczek jest minimalny.
Główne procedury systemu są wywoływane poprzez tablicę skoków. Oznacza to, że adresy ich są jednakowe we wszystkich wersjach Atari. Pozostałe procedury mogą mieć w niektórych wersjach systemu nieco odmienne adresy. Przed ich wykorzystaniem należy zawsze sprawdzić, czy znajdują się one w podanym tu miejscu.
Czyli nie można winić Zientary, ale tych co nie doczytują wszystkiego ;)
Draco ma absolutną rację. Po to wymyślono tablicę skoków, żeby z niej korzystać. Byli tacy, co nie chcieli i teraz trzeba używać np. Translatora żeby odpalić stare programy :?
Moim zdaniem używanie bezpośrednich skoków do bebechów systemu powinno być ograniczone do mocno uzasadnionych przypadków.
QMEG [...] jest to zwykły ROM przerobiony w ten sposób, że wycięto niektóre procedury [...] a na to miejsce wrzucono procedury własne. To i nie dziwne, że akurat GETCHAR czy w ogóle większość procedur została na swoim miejscu.
Wydaje mi się, że założeniem twórcy QMEGa było zachowanie maksymalnej kompatybilności z programami korzystającymi z "nielegalnych" skoków do środka systemu. Dorobił on nawet punkty początkowe procedur w miejscach, gdzie znajdowały się one w OS A. Dlatego część programów dla 400/800, które krzaczą się w XL OS, działa pod QMEGiem bez problemu.
Podbijam :mrgreen: :twisted: :
Teoretycznie "SIO2IDE ma transfer rzędu 52 kbps, a KMK wyciąga tylko 40 KBps"
Gdyby jednak Marek dorobił funkcje SIO do obsługi plików FAT i CD, to SIO2IDE może rooloo.
(tytułem usprawiedliwienia: mam oba interfejsy) :D
Sor, skrzywienie zawodowe ;)
Ale jak to brzmi: "SIO2IDE ma transfer rzędu 32 kbps, a KMK wyciąga tylko 20 KBps" :twisted:
Kurde, sam się zamieszałem:
http://www.numion.com/Calculators/Units.html
AFAIK kB (albo KB) to nie to samo co kb. Howgh :D
Używanie komend niskiego poziomu (sektor RW) jest możliwe w SIO2IDE 4.X ale myślę, że nie ma potrzeby pisania obsługi FATa na Atari skoro SIO2IDE ma już to wszystko zaimplementowane.
Epi tworzy sterownik dla KMK, który tego nie ma, więc i tak musi to zrobić. A jak już pisze obsługę FATa, to czemu nie zrobić uniwersalnej, dla obu interfejsów? A Twoje funkcje sektorowe działają, sprawdzałem, nawet odczytałem katalog peceta :D
Nie ma żadnego problemu żeby dodać nowe komendy SIO, które zapewnią dostęp do wszystkich plików na dysku PC.
To byłoby najlepsze rozwiązanie, bo wtedy prawie w całości sprzętowo (z punktu widzenia Atari) załatwiłoby się FATa 16,32 i CDFS, bez pisania ogromnych sterowników.
Jestem za :!:
Czekam na ewentualne pomysły rozszerzeń do SIO2IDE i w razie potrzeby służę pomocą.
Oto moja księga życzeń (póki nie ma osobnego wątku): ;)
- tworzenie ATRów za pomocą polecenia SIO.
- możliwość odczytu długich nazw plików na bieżąco bez buforowania (już Ci kiedyś o tym pisałem).
- możliwość zamontowania napędu (dysku CD) bez pliku cfg. Oprogramowaniem wybierałoby się ATRy i montowało - użyteczne przy CD.
- możliwość obsługi dwóch urządzeń jednocześnie, ale bez przełączania.
- jak wyżej - komendy do odczytu plików z partycji FAT i CDFS.
Procedurki poszły na PM ;)
A FAT32 - koniecznie :!:
Miałem na myśli, że niemam nic nt. ARClock'a - ani samego zegarka.
Tu masz opisy ARCa:
Rejestry:
http://www.serious-dial.atari.pl/SSerious/S12/A06.html
Budowa:
http://www.serious-dial.atari.pl/SSerious/S12/A07.html
W SIO2IDE tablica partycji jest PCtowa, a ATRy to zwykłe pliki na FAT. Niestety, jest to widziane w ten sposób tylko wewnętrznie przez interfejs, Atarka widzi tylko zwykłe D1:-D8:.
Natomiast SIO2IDE też ma bezpośredni dostęp do fizycznego sektora w wersji 4.x. Problem odczytu FATa na SIO2IDE 4.x jest więc chyba taki sam jak w KMK. Dlatego zamiast pisać dwóch sterowników np. dla SDX (jeden dla KMK, drugi dla SIO2IDE) można napisać jeden, który by wołał odpowiednią procedurkę odczytu fizycznego sektora (dla KMK, SIO2IDE, a nawet zwykłej stacji czytającej PCtowe dyskietki). Można by w ten sposób jednocześnie obsługiwać wszystkie urządzenia, a są tacy co mają oba interfejsy ;)
Sam się już prawie zabierałem za FATa, ale po co robić we dwóch to samo. Mogę podesłać procedurki dla SIO2IDE, jeśli chcesz.
Wyobrażam sobie to w ten sposób, że jesli flaga sygnalizuje żeby program załadować do RAM-u powyżej 64k, to loader ma to zrobić, o ile ta pamięć istnieje i jest w niej miejsce.
Zastanawiam się nad programami dla 6502, które korzystają z dodatkowej bankowanej pamięci (PORTB). Gdyby loader wiedział o tym, ktore banki są do dyspozycji i przydzielał (na sugestię) bloki pamięci rozszerzonej, a program używał tych przydzielonych banków to nie trzeba byłoby wybierać banków, nie ma napisywania ramdysku itp.
Na specjalne życzenie truba...
dzięki :D
...który chce, żeby program składał się nie tylko z oddzielnych segmentów na kod i dane, ale wręcz z oddzielnie ładowanych i uruchamianych porcji kodu,
Nie do końca o to mi chodziło, ale nowy sposób ładowania w pętli daje rzeczywiście nowe możliwości, np. umieszczanie porcji programu w różnych rodzajach pamięci.
Ale to będzie jeden program, bo nie mamy multitaskingu. Jeśli jeden program wykorzystuje drugi jako zestaw podprogramów do wywołania, to trudno doprawdy nazwać to komunikacją pomiędzy programami.
Chodzi Ci chyba o komunikację między procesami - tego faktycznie nie ma. Ale w przypadku SDX jeden program może udostępniać funkcje innym, zewnętrznym programom. Ich programiści nie muszą wcześniej wiedzieć pod jaki adres skoczyć, co w przypadku relokacji jest ważne. Wystarczy, że znają nazwę funkcji. Dlatego mówimy o komunikacji między programami, a nie procesami. A samo wywoływanie funkcji często jest elementem komunikacji między procesami. RPC, jeden z pierwszych mechanizmów tego typu to nic innego jak takie wywoływanie. Nie ma co porównywać, ale idea jest podobna. Mechaniżm symboli w SDX do złudzenia przypomina natomiast biblioteki DLL, które firma M. wprowadziła dobrych kilka lat później :lol:
rozważania PO CO kazać wyrównywać adresy do granicy stron naprawdę trochę wybiegają poza główny nurt tej dyskusji
Jeżeli loader przydziela pamięć, to może się okazać, że istnieją dodatkowe warunki tego przydziału. Spróbuj np. uruchomić TD.COM z bardzo niskim memlo. Kaszana w połowie linii bierze się stąd, że pamięć obrazu została przydzielona na granicy 4kB, bo Sparta wszystko ładuje jak leci pod memlo. Jest to jedna z rzeczy, których nie trzeba teraz uwzględniać, ale można by zostawić dla niej miejsce, jeżeli chcemy by format był uniwersalny.
Wystarczy spojrzeć na ołners maniual. Na moim jest jak najbardziej napisane PERSONAL COMPUTER i ja w to wierzę ;)
Spokojnie Drac030. Po pierwsze loader plików relokowalnych już dawno był potrzebny i chwała Ci za to, że go napisałeś wraz z narzędziem do przygotowywania takich plików.
Moje wątpliwości dotyczą właśnie formatu, który proponujesz. Twoja pierwotna propozycja mi wydaje się zbyt uboga w porównaniu do formatu użytego w SDX. Sam piszesz, że dodałeś do niej nowe rzeczy już w trakcie trwania tego wątku, np. symbole. O to mi chodziło, dlatego mógłbyś to nieco szerzej opisać (jak nie dla mnie to może dla laoo albo krapa :) ).
skąd ci się wzięła uporczywie przez ciebie lansowana koncepcja, że proponowany przez mnie format pliku relokowalnego nie może być, bądź też ma nie być tworzony przez kompilator?
...przy okazji format można lepiej zdefiniować i szerzej wykorzystać; dlatego w ogóle poddałem to pod dyskusję.
No właśnie, a jeżeli będzie już tworzona przez kompilator, to może warto się zastanowić, czy nie wykorzystać tego do bardziej zaawansowanych celów niż sama relokacja. Chodzi mi tu o dwie rzeczy: współpracę między załadowanymi programami oraz zarządzenie pamięcią. To pierwsze już (jak piszesz) jest w postaci symboli.
Jeżeli mamy >64kB pamięci, to może też rozwiązać odwieczny problem wykorzystania dodatkowych banków w taki sposób, aby to loader, a nie program decydował, które banki należy przydzielić? A może przy 65816 nie dałoby się umieszczać pewne programy z innym PBR, tak aby miały do dyspozycji więcej ramu? (popraw mnie jak się tego nie da zrobić). Albo wyrównanie kodu do granicy strony, ale nie po to, by załatwić dzielone adresy, ale np. by precyzyjnie liczyć cykle? Ładować dane obrazu tak, aby nie wstrzelić się w granicę 4KB?
Tych rzeczy nie trzeba teraz implementować, ale warto znaleźć dla nich miejsce w nowym formacie, tak aby w miarę upływu czasu nie wywracać wszystkiego do góry nogami.
Jeśli mi nie odpowiesz na to pytanie, tak żeby odpowiedź miała ręce i nogi, to kończę dyskutowanie z tobą;
A szkoda, bo najlepsza dyskusja się dopiero pojawia się na trzeciej stronie ;)
To chyba mylisz komunikację między programami z obsługą wywołań systemu. W SDX jest to przyznaję rozwiązane bardzo pomysłowo, ale niewiele ma to wspólnego z tematem.
Nie mylę, bo możesz napisać dwa programy relokowalne, załadować je równocześnie i wzajemnie wywoływać funkcje za pomocą nowych symboli.
Może nie do końca to komunikacja w stylu semaforów i kolejek komunikatów, ale jak na Atarkę całkiem fajna.
Zobacz przykład nadajnika i odbiornika z dokumentacji Fast Assemblera.
Ja w ten sposób zabrałem się za pisanie nowego sterownika do XEP-80 pod Spartę. Niestety z braku czasu projekt śpi. Składa się z trzech relokowalnych programów (sterowników), ładowanych w miarę potrzeby: jeden to podstawowa obsługa XEPa, drugi to obsługa konsoli, trzeci drukarki XEPowej. Można też dopisać czwarty sterownik S:. Za pomocą symboli programy wywołują wzajemnie swoje funkcje. Użytkownik ładuje tylko to czego potrzebuje. Chciałbym, żeby taka możliwość była w nowym formacie, bo jak na razie taka struktura jest możliwa tylko w SDX.
atari.area forum » Posty przez trub
Wygenerowano w 0.029 sekund, wykonano 43 zapytań