Tak na szybko:
Od strony C64: zapis do I/O2 powoduje zapamiętanie danej w rejestrze. I wygenerowanie NMI dla drugiego proca, które jest ściągane gdy odczyta on z obszaru $7Fxx.
Od strony drugiego proca: zapisuje pod obszar $7Fxx, to jednocześnie generuje NMI dla C64 - a zdejmowane jest gdy C64 odczyta z I/O2.
Przestrzeń adresowa "szybkiego proca":
- dolne 8 kB - SRAM (3 najstarsze bity adresowe zero - hgw po co to A14 podpinane, gdy nie doczepione A13 no i jeszcze dekodowanie adresu przy użyciu A15...A13)
- okienko na dane pod $7Fxx
- górne 32 kB - Eprom
Przestrzeń adresowa C64:
- I/O2 - dane wymienianie z drugim procem
- I/O1 - rejestr sterujący (no.. nie jest to F3, chociaż ta sama firma robiła), zerowany na starcie
D0 -> A14 Epromu (tego dla C64) czyli bankowanie
D1 -> EXROM i GAME
D7 -> OFF (wyłączenie rejestru sterującego), 1 wyłącza
Możliwe przeróbki: '174 ma jeszcze 3 wolne rejestry, można by wpakować większy Eprom, tylko że to od strony C64. Albo... o tym później
Trochę boli to, że dekodowanie obszarów I/O jest niepełne - znaczy wszystko zajęte.
Wygląda na to, że "handshake" zrobiony jest w obie strony przez NMI - że niby jak przyjdzie NMI, odczytamy daną wystawioną przez drugą stronę i NMI zostanie zdjęte.
Ale... hm... oba rejestry '74 mają na wejścia masę, ustawiane asynchronicznie przez !PRE. A kasowanie jest robione przez wczytanie tego stałego zera z wejścia D. Gdyby tak podpiąć ze '174 dwa z wolnych wyjść na wejścia D do '74, można by tam zamiast 0 podawać 1 (nawet indywidualnie - oddzielnie dla C64 i oddzielnie dla szybkiego CPU) a to by oznaczało, że odczyt z rejestru "wejściowego" nie wyczyści NMI.
Po co ? Żeby w jednym NMI odczytać się dało więcej niż 1 bajt. Tylko cyklowanie konieczne, coś jak w różnych fastloaderach. Wada: to od strony C64 można by sterować zachowaniem NMI - tj. włączaniem/wyłączaniem jego "przeciągania".
Amen.
