http://whizzosoftware.com/sio2arduino/vapi.html

Mamy taki BCB:

bcb_transfer:
?srcad  .long SOURCE
?srcdy  .word 1
?srcdx  .byte 0
?dstad  .long TARGET
?dstdy  .word 1
?dstdx  .byte 0
?width  .word 1-1
?height .byte 64-1
?and    .byte %00000000
?xor    .byte %00000000
?coll   .byte %00000000
?zoom   .byte $00
?patt   .byte %00000000
?mode   .byte 1  ;TRANSPARENTCOPY

Jak VBXE to wykona? Czy pobierze BCB i:
1. zorientuje się że w wyniku AND i XOR  jest zawsze 0 i pominie wykonanie blita - czyli skończy tylko na pobraniu BCB?
2. będzie pobierać dane z SOURCE 64 razy, ale nie zapisze niczego w TARGET?

Mapper oparty o RAM byłby chyba najszybszym rozwiązaniem, bo podejrzewam że wyzwaniem tutaj są reżimy czasowe związane z dostępem do odpowiedniego carta na magistrali.
Czy trzeba by aż FPGA to nie wiem. Wyobrażam sobie to np tak, że taki mapper mógłby być cartridgem diagnostycznym z własną pamięcią EEPROM do zachowania ustawień. Przy włączeniu komputera taki cart startuje, mapuje sobie ROM w $A000..$BFFF i przepisuje ustawienia z EEPROM do własnego RAM używanego właśnie do mapowania (może też na jakąś kombinację klawiszy wchodzić do edytora i umożliwiać modyfikację mapy i jej zapis w EEPROM). Potem cart wraca do OS-a z już skonfigurowanym mapowaniem i pozwala na normalną pracę całego systemu (mógłby co najwyżej jeszcze przed powrotem zorientować się czy nie jest aktywny jakiś inny cart diagnostyczny żeby przekazać mu sterowanie).
Ponieważ mapowane są tylko rejestry na $D5 to wystarczy 256 komórek RAM o szerokości 12-bit - ten RAM używany byłby wyłącznie do przemapowywania adresów na stronie $D5 kiedy sygnał CCTL jest aktywny czyli trzymałby ustawienia A0..A7 kierowanych na magistralę adresową cartów - sygnały A8..A12 nie są przemapowywane. Za to w RAM trzeba jeszcze dodatkowo trzymać informację o numerze carta, który ma być uaktywniany CCTL-em.
Kiedy S4 lub S5 są aktywne ta mapa nie jest używana, ale potrzebny byłby dodatkowo jeden rejestr do wyboru carta mapującego swoje obszary adresowe $8000..$9FFF i $A000..$BFFF. Powiedzmy że dolna połówka odpowiadałaby za nr carta dla obszaru $A000..$BFFF, a górna za $8000..$9FFF - ten selektor też odpowiadałby za to, z których cartów byłyby przyjmowane sygnały RD4 i RD5.
Czyli z grubsza:
- 2 demultipleksery dla R/W i FI2 Edit: a może nawet nie są potrzebne,
- RAM dla A0..A7 i nru carta + dekoder 1 z N dla CCTL,
- rejestr 4-bit + dekoder dla S4 + multiplekser RD4 do obsługi $8000..$9FFF,
- rejestr 4-bit + dekoder dla S5 + multiplekser RD5 do $A000..$BFFF,
- no i pewnie bufory dla magistrali danych + trochę logiki żeby mapowanie odbywało się tylko dla CCTL.
W przestrzeni adresowej Atari musiałyby być dostępne rejestry do:
- adresowania EEPROM mappera (adres, wartość)
- adresowania RAM mappera (adres, wartość)
- rejestr selekcji cartów dla obszarów $8000..$9FFF i $A000..$BFFF,
- i pewnie jakiś rejestr aktywujący/deaktywujący mapper żeby można było modyfikować konfigurację w EEPROM.
To oczywiście zarys fabuły. Diabeł jak zawsze tkwi w szczegółach...
Może zamiast RAM dałoby się tam wsadzić jakiś programowany układ kombinacyjny, który zależnie od stanu wejść wystawiałby wyjścia?

Edit: Właśnie mapper załatwiałby całkowicie kwestię dekodera. Żaden konstruktor cartridgy nie musiałby robić pełnego dekodera (zresztą w istniejących cartach rzadko który ma pełny dekoder) - precyzyjne adresowanie robiłby sam mapper.

Edit 2: Sloty po N bajtów dla każdego carta na stronie $D5 nie są dobrym pomysłem ze względu na to że tam jest tłoczno. Niektóre cartridge z bankowaną pamięcią potrafią zająć pół strony (bo przełączanie banków polega na odczycie konkretnego adresu $D5xx) i na inne urządzenia robi się mało miejsca. Poza tym nie ma reguły gdzie taki cart będzie miał swoje rejestry - czy na początku strony, czy może na końcu? A chodzi o to, żeby tę stronę jednak wykorzystać do maksimum. Gdyby EEPROM miał więcej bajtów, to można by w nim trzymać presety.

Edit 3: Właściwie to gdyby zastosować PLD który programowany byłby na etapie edycji ustawień mappera, to całe urządzenie mogłoby (chyba) być zrealizowane tylko za jego pomocą. Mamy wtedy jeden układ kombinacyjny i może udałoby się spełnić nawet restrykcje czasowe na magistrali gdyby układ był dość szybki. W przestrzeni adresowej Atari trzeba byłoby mieć wtedy tylko rejestry do EEPROM-u, rejestry do programowania PLD (niedostępne kiedy mapper jest aktywny) i rejestr aktywujący mapper. A oprogramowanie konfiguracyjne mogłoby być nawet w postaci pliku .XEX bo raz zaprogramowany PLD działałby już zawsze aż do kolejnej zmiany.

Nie umim :/ Podejrzewam, że trzeba by skompilować biblioteki resid i ayemu dla Win$. Ściągnięcie mingw i podanie dodatkowo --target=windx przy ./configure wykłada mi się na bibliotekach DirectX.
Może ktoś bardziej obeznany w tych rzeczach mógłby to skompilować, albo przynajmniej przygotować jakąś instrukcję?

Edit: W moim przypadku w grę wchodzi kroskompilacja - nie mam i nie używam Windowsa.

@Cyprian: Wspominałem mu o tym, ale on niechętnie podchodzi do sprawy.
Więc zrobiłem emulację AY i SID-a w atari800. Obecnie mam zaimplementowane Evie (bez COVOX-a i filtrów SID-a) i SlghtSID-a (obydwie wersje), ale w ciągu weekendu dopiszę SIDari i SONari więc poczekajcie cierpliwie.

Edit: Zresztą jeśli ktoś chce to poniżej instrukcja:

W http://mono.atari.pl/atari800/atari800-github.zip znajduje się skompresowane repozytorium git z implementacją SlightSID-a i Evie. Do kompilacji potrzebne są biblioteki:
- libc++
- libayemu 1.0.0: https://github.com/gasman/libayemu
- libresid 0.16: http://www.zimmers.net/anonftp/pub/cbm/ … index.html

Ja kompiluję to tak:
$ ./configure \
    --enable-monitorbreakpoints \
    --enable-monitorprofile \
    --enable-monitortrace \
    --enable-seriosound \
    --enable-volonlysound \
    --enable-synchronized_sound \
    --enable-sid_emulation \
    --enable-psg_emulation
$ make
Ten build przygotowywany jest u mnie dla SDL.
Do testów można próbować:
- http://mono.i-demo.pl/sidplay/sidplayh.zip (SID)
- http://mono.i-demo.pl/psgplay/psgplayh.zip (PSG)

Evie 1.0 taktuje SID-a inną częstotliwością niż SlightSID. Evie 2.0 ma już identycznie jak w SlightSID dzięki czemu można sobie posłuchać kawałków na 3xSID. W obydwóch wersjach Evie znajduje się jeden YM.

Edit: linki zmienione z mono.atari.pl na mono.i-demo.pl

Różnicy w oprogramowaniu nie ma. Czy jest różnica w brzmieniu tego nie umiem stwierdzić. Ale np Yerz pisze specjalne wersje swoich utworów na YM, co by oznaczało że coś na rzeczy jest... No chyba że perfidnie kłamie :)

Świetnie.

Dziękuję.

Nie wiem, czy ktoś je robi. Dokumentacja jest na stronie Autora: http://raven1.magix.net/sonari/sonari.html a playerek dla utworów .PT3 z ProTrakera3 z ZX (2xAY) jest w trakcie pisania, więc jeśli już ktoś to będzie robił polecam wersję Sonari z dwoma AY/YM. Tym bardziej że urządzenie jest tak zaprojektowane że można wsadzić do niego tylko jeden układ (AY lub YM) jeśli ktoś nie chce/nie ma obydwóch.

Edit: Jest już gotowy player plików .STC (Sound Tracker 1.1 z ZX), ale wymaga jeszcze selekcji utworów demonstracyjnych. Wkrótce będzie dostępny.

Mógłbyś zrzucić zawartość taśmy? Tych pierwszych wersji nie ma w sieci - są tylko albo jakieś cracki, albo wersje z muzyką :/. A oryginału ni-ma...

Uwaga, bo w $D22x i $D23x drzemią sobie 3ci i 4ty POKEY.

Edit: Aha, o rozmrażarce kanałów POKEY-owych nie słyszałem :) Chociaż są jakieś sprzętowe detektory stereo które generują dźwięk z jednego POKEYa na obu kanałach stereo.

@Yosh: A co myślałbyś o takim fjuczerze?
Z rozmów z Tobą zrozumiałem, że generujesz kod wykonywany przez Atari, który bierze daną z rejestru i zapisuje w pamięci. A gdyby tak na dysku znajdował się gotowy program podzielony na bloki jednostronicowe o początku w obszarze carta $D500. Takie bloki ładowałbyś z dysku, podstawiał jako pamięć w $D500 i wykonywał (przez Atari) tak jak to robisz obecnie (ten kod musiałby oczywiście wiedzieć jak pobrać daną z Twojego sprzętu). Dałoby to użyszkodnikowi możliwość praktycznie bezpośredniego wykonania kodu ładowanego z dysku sektor po sektorze. Owszem - niebezpieczne. Ale wtedy znikają pytania o możliwość odtwarzania dźwięku, multiplikacji sprajtów itd.

Edit: Może te bloki mogłyby być większe, albo wręcz zawijane na stronie $D5 (nie pamiętam jak masz to dokładnie zrealizowane).

Edit 2: Albo może dałoby się zrealizować w jakiś sposób mapowanie gdzie do pamięci mają trafić konkretne bajty z sektora z dysku. Wtedy program generowałbyś sobie tak jak dotąd bazując na takiej mapie. Choć wykonanie kodu bezpośrednio z dysku dałoby znacznie większe możliwości zarówno jeśli chodzi o kompresję danych graficznych (zapis tylko danych które się zmieniły), sprajtów, dźwięku itp.