http://mono.atari.pl/psgplay/psgplayh.atr
Odpalamy:

PSGPLAYH /A $D560 SPEJS

Moje programiki można konfigurować podając adres karty za pomocą /A adres, więc docelowy adres urządzenia nie jest wielkim problemem. Domyślnie przyjmowany jest adres bazowy $D500.
Jeśli dobrze widzę adres bazowy SONari może być skonfigurowany za pomocą jumperów SJ3..10 (wg schematu http://raven1.magix.net/sonari/SONari_stereo.pdf) co $20 bajtów. Ponieważ SlightSID siedzi sobie w obszarze $D500..$D542, to może niech adres bazowy SONari byłby w $D560? To będzie Y3 (czyli SJ6) zwarty?

Edit: Pamiętajcie jeszcze o SJ1 i SJ2 jak nie chcecie żeby programy wypisywały Wam że znalazły AY a macie wsadzone YM :)

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?