No niby tak, ale skąd ma czytać?
Covox może być pod różnymi adresami :/ Wiem o najpopularniejszych (NEO Tracker, XL digital DEMO haha) pod:
- D500
- D600
- D700
- D220
- D240
- D260
- D280
Może w takim razie lutować rezystor i zależnie od adresu odczytywać inną wartość?
Zawsze to jeden, dwa rezystory powiedzmy 4.7k a nie 30...

Detekcja kowoksa jest prosta: jak gra to słychać

rozumiem, ze soft ktory ew. mialby wykryc covoxa potrafi na nim grac?
ja proponuje takie rozwiazanie:
1. program gra domyslnie na pokeyu/covoxie ale klawiszem mozna zmieniac pomiedzy covoxem/pokeyem,
2. zmienna srodowiskowa w sparta dosie msx_unit=pokey|covox.

pamietam, ze pin mowil mi o tym juz jakis czas temu. sugerowalem mu rozwiazanie nr 1.

slaby punkt takiego rozwiazania to koniecznosc ustalenia dwoch stalych adresow do odczytu adresu covoxa...

O ludzie, toż to temat stary jak świat. Epij, jesteś?

Ponieważ widzę, że Epij śpi to może sam się wypowiem.

Rozwiązanie o jakim myśleliśmy owszem, opierało się na paddlach ale polegało na podpięciu kowoksa pod paddla. Czyli nie tak jak mówi mono (może jakieś przekłamania na linii wystąpiły), że podpinamy paddle do masy. No i teraz gramy na covoxie na kolejnych adresach i patrzymy co się na paddlu pojawia.

Myślałem o tym, żeby przyjąć wartości paddles (z tolerancją), które wskazywałyby adres covoxa np.
* 0 - $D500
* $10 - $D600
* $20 - $D700
* $30 - $D220
itd.
W końcu jeśli już ktoś montuje covoxa (do użytku z istniejącym softem), to robi to raczej pod jakimś "standardowym" adresem, a nie np. w $D7EC.
Zdecydowanie nie podoba mi się pomysł z szukaniem covoxa po całym dostępnym obszarze I/O, bo cholera wie co akurat ktoś ma pod $D600? Zapis gdzieś a nuż włączy jakieś przerwanie i bez procedury obsługi (której prawdopodobnie nie ma w systemie) zablokuje kompa. A na paddlu (sprzętowym - cienie w xl/xe wskazują wartości z paddli 0..3) będzie albo 226 (z tolerancją) kiedy nic nie jest podpięte, albo wartość znacznie niższa wskazująca nam symbolicznie lokację covoxa zamontowanego w sprzęcie.
@Fox: Możesz powiedzieć coś więcej nt jumperów w 1200XL?

Edit: "Zapis włączy przerwania" (...) Analogicznie odczyt - kto da sobie głowę uciąć, że elektronika przy odczycie rejestru nie zmienia np. jakichś banków pamięci, romu, generuje dźwięku, włącza pralkę, whatever.

Na pigwie znalazłem REV010A.ROM i tam rzeczywiście widać:

C458: A2 03     LDX #$03
C45A: BD 04 D2  LDA $D204,X ;POT4
C45D: 0A        ASL
C45E: 2E 0E 03  ROL $030E   ;ADDCOR
C461: CA        DEX
C462: 10 F6     BPL $C45A
C464: AD 32 02  LDA $0232   ;SSKCTL
C467: 8D 0F D2  STA $D20F   ;SKCTL
C46A: 58        CLI
C46B: AD 0E 03  LDA $030E   ;ADDCOR
C46E: 6A        ROR
C46F: B0 19     BCS $C48A
C471: A5 01     LDA $01     ;NGFLAG
C473: D0 15     BNE $C48A
C475: AD 01 D3  LDA $D301   ;PORTB
C478: 29 7F     AND #$7F
C47A: 8D 01 D3  STA $D301   ;PORTB
C47D: A9 02     LDA #$02
C47F: 8D F3 02  STA $02F3   ;CHACT
C482: A9 E0     LDA #$E0
C484: 8D F4 02  STA $02F4   ;CHBAS
C487: 4C 03 50  JMP $5003

że jeśli jumper P4 jest zwarty (POT4.7=0) i wystąpiły błędy przy testowaniu ROMu lub RAMu (NGFLAG=0), to wchodzi się do SELF-TESTu. Stan P4..P7 dostępny jest w rejestrze $30E w bitach 0..3, ale nie wygląda mi na to, żeby gdziekolwiek OS tego używał poza procedurą RESET. Czy normalnie te jumpery są zwarte? Kto z posiadaczy 1200XL mógłby powiedzieć, jakie wartości zwraca PEEK(53764)..PEEK(53767)? Może to jest używane do celów serwisowych?
Ale to w zasadzie na boku, bo nadal można wykorzystać P5..7.

Tia, zmienna środowiskowa byłaby najlepsza. Tylko że jedna jedyna Sparta X je ma.

<teoretyzując dalej> Zmienna środowiskowa jest w gruncie rzeczy kompromisem pomiędzy detekcją automatyczną a opisaną przez epiego konfiguracją ręczną. Primo, program chcący się dowiedzieć, czy i gdzie jest taki covox, odczytuje tę informację automatycznie, w jeden, konkretnie zdefiniowany sposób. Secundo, nie potrzebuje z drugiej strony żadnego instalatora czy menu.

To od tego między innymi jest system operacyjny, żeby przechowywał i udostępniał tego typu informacje o komputerze, w tym o sprzęcie. A czy pozyska je automatycznie czy też od usera (przez jakiś centralny plik konfiguracyjny) to już nie jest zmartwienie programu od covoxa.

Oczywiście zaraz odezwą się tacy, którym OS przeszkadza. No cóż. Mimo wszystko moim zdaniem ta droga jest najłatwiejsza i najsensowniejsza. Z zastrzeżeniem jak wyżej, że OS musi mieć tę informację i ją móc udostępnić, a nie służyć tylko jako prymitywny loaderek do niektórych gierek.

Procedura do rozszerzenia wg pomysłu Pina:

covoxdetect:
  lda #%11111011  ;20ms
  and skctls  ;$232
  sta skctls  ;$232
  sta skctl   ;$d20f
  lda #%00010000
  sta potgo   ;$d20b
?wait:
  bit potst   ;$d208
  bne ?wait
  lda pot4    ;$d204 lub 5,6,7 co tam sobie wybierzemy
  ldx #6
?loop:
  cmp potvalue,x
  bcc ?addr
  dex
  bpl ?loop
?addr:
  lda baseadl,x
  ldy baseadh,x
  rts
potvalue dta b($70),b($60),b($50),b($40),b($30),b($20),b($10)
baseadl dta l($d500),l($d600),l($d700),l($d220),l($d240),l($d260),l($d280)
baseadh dta h($d500),h($d600),h($d700),h($d220),h($d240),h($d260),h($d280)

C=1 na wyjściu - nie ma covoxa wpp YA-adres bazowy, X-indeks urządzenia w tablicy (jeśli by do czegoś komuś był potrzebny).

@Candle: Oczywiście, bo każde inne rozwiązanie wymaga dołożenia już kawałka elektroniki. A jeśli już trzeba kostkę, to nie będzie przecież wisieć w powietrzu - więc trzeba płytkę. Płytkę na kołku dystansowym pasowałoby zamocować, albo przynajmniej na silikonie (:D:D) przykleić. Robi się z tego straszne rozszerzenie. Pomysł pina/epiego/xana wymaga przylutowania 1 kabelka, a zyskujemy możliwość zwykłej detekcji.

Edit: Zapomniałem o odpaleniu przetwarzania (uzupełniam wyżej).