Niesamowite - Nexuss na carcie, choć też zepsuty. Ale odkrycie jest fajne - wielkie dzięki za podrążenie tematu i za poprawkę!

Zanabyłem drogą kupna 130XE SECAM od Bitmana i stwierdzam, że FGTIA poprawnie generuje wszystkie sprajty i obsługuje kolizje (testowane na SysInfo2), ma 8 odcieni i zarówno tryby ANTIC-a, jak i GTIA wyświetla poprawnie.

Dzięki Panowie. Poczytałem wątki, w których pisaliście o różnych modelach. Niestety LG M1721A nie udało się namierzyć, ale zamówiłem LG FLATRON M1917A i zobaczymy jak się będzie sprawować. Obadam rzecz jak już przyjdzie i zdam relację.

Tak czułem niestety. Szkoda. Ale zrobię w wolnej chwili jednak test, bo kto wie - może wszyscy będziemy zaskoczeni :) Dzięki.

Wszystko to znajdziesz u Zientary w "Procedurach Wejścia/Wyjścia": http://tajemnice.atari8.info/ksiazki/index.html
Można spojrzeć do "Procedur interpretera BASIC-a" w jaki sposób realizowane jest LOCATE - wydaje mi się, że x i y należało wstawić do COLCRS i ROWCRS po czym wykonać GET (PLOT analogicznie, ale z PUT-em). Ale głowy nie dam.

Chciałbyś wprowadzić na forum element baśniowy?

Dziękuję, płytki dotarły całe i zdrowe.

Testujesz i sterujesz rejestry cienie, które są aktualizowane na przerwaniu VBLK. To powoduje, że od fizycznej zmiany stanu joysticka do aktualizacji rejestru PTRIG może minąć prawie cała ramka czyli 312 linii skanningowych (PAL). Następnie na podstawie cienia ustawiasz stan rejestru cienia dla koloru COLOR2 - zostanie on zaktualizowany dopiero przy następnym VBLK - czyli po kolejnych prawie 312 liniach skanningowych. Co więcej sterujesz COLPF2 a więc obszar tła w trybie GR.0 a więc kolor zieniany jest w ograniczonym obszarze. Więc przy Twojej metodzie pomiaru miną min 1 a max 2 ramki ekranu w reakcji na wychylenie joystickiem.
Ile to może zabrać czasu? 114 cykli na linię * 312 linii skanningowych / 1773447 Hz = 20 ms. To jest czas trwania ramki w PAL.
Proponuję użyć rejestrów hardwareowych, wtedy na natychmiastową zmianę stanu joysticka będzie można natychmiast zmienić kolor tła ekranu. Proponuję też wyświetlać ekran pusty i zmieniać kolor ramki ekranu w reakcji nie na wychylenie joysticka, ale na stan przycisku.

RTCLOK = $12
TRIG0 = $D010
COLBAK = $D01A
DMACTL = $D400
NMIEN = $D40E
NMIRES = $D40F

  lda RTCLOK+2
sync:
  cmp RTCLOK+2
  beq sync
  lda #$00
  sta DMACTL
  sta NMIEN
  sta NMIRES
loop:
  ldx #$00
  lda TRIG0
  bne skip
  ldx #$0F
skip:
  stx COLBAK
  jmp loop

Monitor CRT powinien dać opóźnienie od 0 do 20 ms, ponieważ fotorezystor bada punkt na ekranie, przez który przebiegnie plamka (pewnie jakiś obszar) a przecież wciśnięcie przycisku mogło się zdarzyć w pierwszej linii skanningowej, a badanie plamki w ostatniej. Reakcja na zmianę stanu przycisku odbywa się w ciągu 12 cykli CPU więc w ok. 7us i to właściwie powinien być najkrótszy obserwowalny czas reakcji CRT.
Wydaje mi się, że w ten sposób dałoby się precyzyjniej określić opóźnienie LCD, ale cudów nie oczekiwałbym - podejrzewam, że czas reakcji skróci się o 20..50 ms.
Przerwania NMI wyłączam ze względu na odświeżanie rejestrów hardwareowych na podstawie rejestrów cieni na VBLK.

Edit: Może nie prościej, ale czy nie lepiej byłoby zamiast testować stan joysticka badać skok sygnału luminancji a element światłoczuły ustawić na górze ekranu? I mrugać wtedy ekranem co np. 1s?

A mógłbyś powiedzieć gdzie ten czeski sklepik?

Kiedyś widziałem ogłoszenie o takiej mniej więcej wymowie: "Kupię mieszkanie 2-pokojowe w rozsądnej cenie, uwzględniającej zarobki na podkarpaciu". Uwzględnilibyście?

Wewnętrzne BASIC-i i gry (XEGS) mimo, że leżą w tym samym obszarze adresowym co cart ($A000..$BFFF) są obsługiwane bitami PORTB ($D301). Natomiast prawdziwy cart po włożeniu do slota sygnalizuje ten fakt w rejestrze TRIG3 ($D013) i ten właśnie rejestr sprawdza OS na przerwaniu VBLKD porównując go z GINTLK ($3FA) - jeśli się różnią następuje JMP * co powoduje zwis komputera.
Sparta obchodzi to blokując drugą fazę VBLK przez SEI, przełącza carta po czym aktualizuje zawartość GINTLK. Ot i cała sztuka. Więc rygor o którym pisze toriman1 da się obejść instalując sekwencję rozkazów LDA TRIG3; STA GINTLK na VBLKI, bo to jest ograniczenie OS-a a nie hardware.
Nie jestem pewny czy carty które mają tylko rejestry na $D5 powodują ustawienie TRIG3. Edit: Jestem już pewny - wystawienie RD5 przez carta powoduje ustawienie TRIG3, a carty urządzeń zazwyczaj tego nie robią - tylko carty z pamięcią w $A000..$BFFF.

@toriman1: Pinokiu chodzi o mapowanie adresów pod którymi rejestry różnych cartów są widoczne na $D5. Wtedy carty mogłyby mieć bardzo prostą konstrukcję dekodera adresów, ale mapper pozwalałby lokować ich rejestry w prawie dowolnie wybranych obszarach I/O, co pozwoliłoby na włączenie naraz SONari, SIDari, YAMari, SlightSID-a, samplera od Mirage, SIDE i co tam jeszcze kto chce, ale z rejestrami każdego z tych cartów dostępnymi w innych obszarach $D5.
Wydaje mi się, że taki mapper można zrealizować jakąś szybką pamięcią na wejściu której podasz adres, R/W, S4/5 i CCTL a dostaniesz informację o nrze slotu do którego przełączyć adres, dane i informacje o bramkowaniu magistrali danych, sterującej i sygnałów zwrotnych od carta.

Edit: Literówki.

Edit 2: Przykład:

Slot 0: SIDari
Slot 1: SONari
Slot 2: coś co gra muzykę SID-em i AY-kiem.

Mapowanie adresów:
$D500..$D53F RW - aktywacja slotu 0, adres wystawiany dla carta to $D500..$D53F, RW, CCTL i dane przepuszczane
$D540..$D543 RW - aktywacja slotu 1, adres wystawiany dla carta to $D500..$D503, RW, CCTL i dane przepuszczane
$8000..$9FFF R - aktywacja slotu 2, adres bez zmian, RW, S4 i dane przepuszczane
$A000..$BFFF R - aktywacja slotu 2, adres bez zmian, RW, S5 i dane przepuszczane

Slot 0 i 1 jest uaktywniany przy odczycie lub zapisie, slot 2 tylko przy odczycie.
Tylko slot 2 powinien mieć przepuszczane na stałe sygnały RD4 i RD5 - w mapperze mógłby być dostępny rejestr do selekcji slotu, żeby można było przełączać aktywne obszary $8000..$9FFF i $A000..$BFFF z różnych cartów.
Poza tymi obszarami żaden slot nie jest uaktywniany.