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.

Ostatnio edytowany przez mono (2018-12-09 21:40:59)

SlightSid żyje?

Seban żyje na pewno :D