Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
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
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
atari.area forum » Posty przez mono
Miło i przyjemnie czasem się zafortepianić.
Cieszę się, że ktoś to już wymyślił :D Znaczy, że idę dobrym torem.
Edit: Wielkie dzięki. Ta procedura jest lepsza, bo obsługa przerwania może być nawet w x-ram.
Interesuje mnie jak wywoływać procedury z romu kiedy go nie ma :D
Konkretnie chodzi o zagwarantowanie poprawnej obsługi przerwań przez system kiedy podnoszę sobie rom i operuję na ramie pod nim.
Założenia:
1. Nie satysfakcjonuje mnie blokada przerwań na czas operacji na ramie pod romem.
2. Chciałbym wywoływać przerwanie z romu przez jmp ($fffe) zakończone oczywiście przez rti.
Czy poniższy kod zadziała poprawnie? Na początek irq:
;ustawiamy wektory obslugi przerwan w ramie pod romem
sei
lda #0
sta irqen
lda #%11111110
sta portb
ldx <irqproc
ldy >irqproc
stx irqvec ;$fffe
sty irqvec+1 ;$ffff
;opuszczamy rom
lda #%11111111
sta portb
lda #$c0
sta irqen
cli
...
;tu się dalej coś dzieje łącznie z podnoszeniem romu i opuszczaniem bez żadnej synchronizacji
...
irqproc equ *
sta irq_a
lda portb
sta irq_pb
lda #%11111111
sta portb
lda <irqret
pha
lda >irqret
pha
php
lda irq_a
jmp (irqvec) ;$fffe
irqret equ *
lda irq_pb
sta portb
lda irq_a
rti
irq_a org *+1
irq_pb org *+1Żeby spełnić założenia mój kod obsługi irq:
1. Zachowuje konfigurację pamięci.
2. Wstawia flagi i adres procedury odtwarzającej portb na stos.
3. Opuszcza rom i skacze pod $fffe.
Ponieważ flagi odkładane na stos mają celowo ustawiony znacznik I (php w procedurze przerwania - dodatkowo przenosi ono jeszcze flagę B dla przerwań brk) więc po wykonaniu rti z procedury systemowej (do której skaczemy jmp ($fffe)) powinniśmy z blokadą przerwań irq wrócić pod irqret i odtworzyć konfigurację pamięci - prawda? irq, które zdarzy się podczas obsługi nie powinno zostać odebrane, bo ma czekać na skasowanie flagi I. Akumulator w zasadzie mógłby być odtwarzany tylko w irqret, ale zakładam, że może być potrzebny userowi i stąd lda irq_a przed jmp ($fffe).
A teraz ta sama sztuczka tylko dla nmi :)
Jak wiadomo nmi nie można opóźnić (niezależnie od stanu flagi I zawsze jest wykonywana procedura obsługi przerwania) - da się go tylko zablokować, co mi kompletnie nie odpowiada, bo nie wiem w którym momencie przyjdzie mi skorzystać z ramu pod romem.
Czy poniższy kod zadziała poprawnie?
nmiproc equ *
sta nmi_a
lda portb
sta nmi_pb
lda #%11111111
sta portb
lda <nmiret
pha
lda >nmiret
pha
php
lda nmi_a
jmp (nmivec) ;$fffa
nmiret equ *
lda nmi_pb
sta portb
lda nmi_a
rti
nmi_a org *+1
nmi_pb org *+1Implementacja się nie różni od tej dla irq, ale:
1. Mimo, że nmi mogą się przerywać, to w chwili kiedy włączymy rom mamy już obsługę nmi systemową i nie musimy nic przełączać (!) a więc specjalna obsługa potrzebna jest tylko kiedy rom jest podniesiony.
2. Sztuczka z php dalej przydaje się do odwlekania irq.
Najbardziej wrażliwy punkt to moment od przyjęcia przerwania do włączenia romu - 17 cykli. Jeśli vblk i dli nie będą interferować to chyba nie powinno być problemu?
Może ktoś z tym ma jakieś doświadczenia? Będzie to działać poprawnie?
Edit: Oczywiście całe cyklowanie dli pójdzie w kosz, ale na to już nic nie poradzę :(
Bit 3 pbctl odpowiada za przełączanie stanu linii command. Wydaje mi się, że już w momencie kiedy atari czeka na odbiór bajtu statusu jest ona puszczana (stan wysoki). Ponieważ podczas wysyłania nie zdarzy się żaden błąd to po wysłaniu 4 bajtów + crc o ile procedura nie zostanie przerwana klawiszem break, to powina zainicjalizować odczyt statusu a więc ustawić stan linii command w stan wysoki (na odebranie statusu ustawiany jest timeout 2 ramek - 2/50 s w pal). Obsługa klawisza break również powoduje natychmiastowe ustawienie linii w stan wysoki.
Edit:
Warto może jeszcze dodać, że od chwili ściągnięcia command na 0 wykonywany jest kod:
LDX #$01
LOOP1 LDY #$FF
LOOP2 DEY
BNE LOOP2
DEX
BNE LOOP1co daje ok 1285 cykli procesora (726 us?). Ale po wysłaniu komendy raczej nie powinno być wielkich opóźnień (co nie pokrywałoby się z Twoimi spostrzeżeniami).
Może w modemie?
Czy przypadkiem w protokole XF551 nie było tak, że komendy z najwyższym bitem ustawionym nie przełączały stacji w tryb turbo (38400? 57600? pamiętam, że w audf ustawiało się 6)?
O ile pamiętam wyglądało to tak:
1. atari wysyła polecenie w 19200 (pbctl=$34)
2. xf odpowiada ack/nack w 19200 (pbctl=$3c)
3. atari wysyła blok w turbo
4. xf odpowiada ack/nack
W przypadku odbioru bloku przez atari nie ma p4 - nie jestem też pewny czy p4 idzie w 19200 czy w turbo.
Nie wiem, jak jest w przypadku innych stacji i systemów turbo.
@pecus: magnetofon - 600 :D, ale ta prędkość jest w pewnym zakresie zdaje się korygowana podczas odczytu dwóch pierwszych bajtów rekordu zawierających naprzemiennie zera i jedynki ($5555).
...nazywałyby się np. ataraki :D
i Bajteny.
Zerknij na zawartość DVSTAT ($2ea)- można go wypełnić (dla stacji nr 1) za pomocą:
lda #'S'
sta dcmnd ;$302
jsr jdskint ;$e453W DVSTAT dostajesz 4 bajty statusu http://atariki.krap.pl/index.php/SIO#Stacja_dysk.C3.B3w.
Czemu Waść nie spojrzysz w linki, które ludzie dobrzy podają?
Informacje które Ci podałem znajdziesz w książce Zientary "Procedury wejścia/wyjścia" w rozdziale "Sterownik dyskowy": http://tajemnice.atari8.info/ksiazki/zi … yjscia.zip
Napisz napisz. Napisz coś ładnego.
Hmmm. Kto wie, kto wie :) Póki co oglądam sobie.
Nigdy w tę grę nie grałem.
Edit: Przyznam się, że grafika Anj zrobiła na mnie kolosalne wrażenie!
Bardzo dziękuję :)
1. Czas obsługi brk od jsr teoretycznie różni się jednym cyklem zdaje się, ale co jeśli brk zrobisz podczas obsługi irq?
2. Blokada przerwań irq podczas brk może być zaletą lub wadą zależnie od kontekstu.
3. 3 bajty na stosie zamiast 2 - czy to wada, czy zaleta też zależy od kontekstu.
4. Adres powrotu odłożony na stosie można wykorzystać do pobrania parametrów następujących po opkodzie brk, ale trochę z tym zabawy.
5. Konieczność dzielenia wektora brk z irq a co za tym idzie odróżniania źródła przerwania.
Taką "emulację" dowolnego procesora prefiksowaną brk można zrobić softwareowo, ale szybkie to nie będzie :/
Hehe - w ogóle przerwania nie są potrzebne. Rozpraszają tylko człowieka niepotrzebnie ;). Vide Propeller - http://www.parallax.com/tabid/407/Default.aspx (btw. czy ktoś miał okazję tego używać?).
Czy ktoś życzliwy podesłałby aktualny link do tej gry? Chętnie obejrzę wszystko, co Anj robił na Atari (i nie tylko).
jmp (q,x) ;ponoć jest w wersji C
jmp (q),y
jsr (q) + wersje indeksowane
Fajne są rozkazy powrotów warunkowych z z80.
Brakuje mi czasem rozkazów przesłań pojedynczych bitów (takie mov c,bit czy mov c,/bit z mcu51, albo operacji bst, bld z avr).
Przesunięcia rejestrów x i y.
Edit 1: I resetowania watchdoga ;]
Edit 2: Gdyby tak rozpuścić wodze fantazji (niektóre mniej, niektóre bardziej przydatne):
- mnożenie 16x16=32 i dzielenie 32/16=16%16 z i bez znaku z łatwą możliwością rozszerzania precyzji
- swap (mcu51) zamieniający nybbles miejscami
- lustro akumulatora czyli bity 76543210 po operacji byłyby widziane jako 01234567
- 16-bit adres początku stosu (sp może być 8-bit)
- shifty i rotacje z i bez C oraz przesunięcie arytmetyczne w prawo (z kopiowaniem bitu znaku)
- znacznik parzystości liczby bitów
- push/pop dowolnego rejestru na stos
- jednolity adres powrotu dla jsr i dla zgłoszenia przerwania
Edit 3: Właściwie to mając swap i mirror użyteczne przy naszych trybach graficznych 1 i 16-kolorowych, można by rzecz uogólnić jeszcze na tryby 4-kolorowe - taki rozkaz lustrzanego odbicia paczek bitów:
mir #1 ;76543210 -> 01234567
mir #2 ;76543210 -> 10325476
mir #4 ;76543210 -> 32107654
Systematycznych zapisów na pendrive (o ile są przewidywane) nie polecam, ze względu na to, że nie masz żadnej kontroli nad nimi (elektronika pena wewnętrznie organizuje zapisy i zarządzanie blokami flasha) i zmiana fs na pendrive nic nie da (jeśli ktoś ma inne doświadczenia chętnie bym się zapoznał).
Jeśli można to podpiąłbym się pod temat - czy ktoś na kartach CF instalował jakiś fs typu JFFS, YAFFS czy LOGFS? Jakie wrażenia?
@sqward: Dzięki.
@epi: W takim razie nie kłopocz się.
Nie jestem już zainteresowany wersją papierową.
Przepraszam za zamieszanie.
@epi: Wielkie dzięki! :) Byłbym zobowiązany.
@piter: Mogę się podzielić np. poskanować i wystawić w .djvu lub innym .pdf.
Aha, bo nie zauważyłem postscriptum Draco; interesuje mnie tylko reference do Motoroli :)
Ja byłbym zainteresowany, ale muszę kogoś poprosić o odbiór i wysyłkę na mój koszt.
Dzięki Trub. Czyli nie będzie pasować :( Może ta od Jera...
Czy taka folia podejdzie do każdej 65XE?
Moja klawiatura jest made in japan (tak pisze na plastikowej obudowie po zdjęciu pokrywy górnej komputera) i ma symbol katalogowy CO70015-003. Jeśli Twoje folie będą pasować to byłbym zainteresowany 3-ma.
Mapa w grze mówi, że północ (kierunek joya do góry) to lewo-góra.
Ha! Nigdy tego w atariki nie widziałem. Dzięki Panowie za pomoc. Potrzebowałem podać linka a nigdzie tego góglem nie udało się znaleźć... :/
Wielkie dzięki. O to mi chodziło.
atari.area forum » Posty przez mono
Wygenerowano w 0.095 sekund, wykonano 14 zapytań