Czy projektujesz to urządzenie jako coś, co pozwoli trzymać naraz różne carty i NewDevices podłączone i unikać wyjmowania/wkładania? Czy chciałbyś może skonstruować coś co pozwoli jednocześnie współegzystować różnym rozszerzeniom w jednej maszynie?
IMHO te założenia nieco się od siebie różnią. Jakie są moje spostrzeżenia pisałem w Twoim wątku o YaMari. Dodatkowo:
1. Cart to nie tylko kawałek pamięci ROM/RAM mapowany w obszarze $8000..$9FFF + $A000..$BFFF, ale również rozszerzenia (np. sampler, karta muzyczna, Tomek8, Veronica i wiele innych). O ile kawałek pamięci z grą/SDX/GOS/czymkolwiek w zasadzie wyklucza współistnienie drugiego carta z kawałkiem pamięci (choć można się zastanawiać nad przypadkiem RAMCART/SiDiCar), o tyle regularne rozszerzenie powinno dopuszczać współistnienie innych rozszerzeń. Uogólniając można by pozwolić na współistnienie dowolnych cartów.
2. Ponieważ zakłada się, że cart istnieje samodzielnie, to zakłada się, że cart korzysta ze strony $D5 dla swoich rejestrów i może mapować RAM/ROM w obszarach $8000..$9FFF i $A000..$BFFF (wbudowany Atari BASIC w XL/XE i Missile Command w XEGS mają niższy priorytet niż cart). Nieliczne przelotowe carty pozwalają na równoczesne współistnienie innych i wtedy mapują jedynie ograniczoną pulę rejestrów na $D5 dla swoich potrzeb a resztę pozostawiają drugiemu cartowi.
3. Urządzenia PBI (ND) są pomyślane tak, że mogą współistnieć równocześnie w systemie. Są aktywowane rejestrem PDVREG ($D1FF) i tam również pojawia się status np. przerwania. Dzielą wspólny obszar adresowy $D6 i $D7 slotami po $20 bajtów gdzie mogą mapować swoje rejestry, a po aktywacji urządzenia w PDVREG mapuje ono ROM/RAM w obszarze $D800..$DFFF.
4. ND często mają niestety sztywno przypisany numer co powoduje konflikty (ostatnio znana była sprawa zdaje się IDE+ i KarinMaxi, albo SIDE, które nie chciały działać u Pinokia, bo wykorzystywały ten sam numer urządzenia.
Elastyczne proxy do cartów i ND mogłoby:
1. Pozwalać na mapowanie obszarów i dowolne włączanie urządzeń naraz oraz mapowanie identyfikatorów urządzeń ND.
2. Pozwalałoby analogicznie, jak proxy do rozszerzeń o którym dyskutowaliśmy w wątku o YaMari na uproszczenie budowy kolejnych ND i cartów.
3. Umożliwiałoby prostą detekcję cartów/ND i ich adresów.
ale musiałoby mieć jakąś nieulotną pamięć do zachowywania ustawień i logikę pozwalającą na przemapowywanie adresów i włączanie/wyłączanie carta/ND z obsługi.
Może warto by jednak wtedy pomyśleć to, jako proxy do dowolnych rozszerzeń?

Samo mkatr masz w sio2bsd, ale on Ci nie sformatuje zrobionego atra :/ Trzeba odpalić na tym emulator z odpowiednim DOS-em. Franny może zrobić atra, założyć odpowiedni fs i kopiować pliki.

Quake ma świetny klimat na takim oscyloskopie.

Ponieważ każdy bajt w buforze to kolumna grafiki, to wystarczy wyrzucać go do drukarki od tyłu. A jutro dorobię Ci parametr do odwracanie bufora.

O to by było bardzo miłe.

2.097 MHz?

Edit: I co to za OS z 12.01.2015?

Rozumiem. Nie upieram się przy $D4, ogólnie chodzi mi o to, żeby nie nastręczać konstruktorom nowych urządzeń kłopotów, lecz jednak zrobić proxy, które pozwoli współdziałać nowym (i starym) rozszerzeniom nie projektowanym jako NewDevices.

Edit: Pod "slotami" nie kryje się u mnie poszatkowanie I/O po $20 bajtów, bo są rozzerzenia, jak COVOX, które wykorzsytują raptem 4 bajty, a inne z kolei potrzebują pół strony. Chciałbym, żeby to było dość elastyczne.

Amstrad CPC 666.

W załączniku procedura przygotowująca bufor linii dla drukarki.
Parametry:
- A0..A7 - adresy początków linii grafiki
- W - szerokość linii w pikselach
- B - adres bufora dla drukarki (musi mieć rozmiar W).
Procedura znajduje się w stałej tekstowej, której adres wskazuje zmienna R i wywołujesz ją za pomocą:

X=USR(R,A0,A1,A2,A3,A4,A5,A6,A7,B,W)

Gdyby okazało się, że grafika jest odbita w pionie to zmień kolejność parametrów A0..A7 na odwrotną (czyli A7..A0).
Ponieważ podajesz adresy, to możesz sobie podać tam albo adresy w RAM, albo rezerwować zmienne tekstowe i podawać ich adresy przez ADR(T$).

Edit: A - procedura używa lokacji $D4..$E7 czyli rejestrów liczb zmienno-przecinkowych FR0, FRE, FR1 i części FR2, ale to nie powinno przeszkadzać. Za to istotne jest, że obszary wskazywane przez A0..A7 są modyfikowane (więc wydruk z ROM-u raczej się nie uda). No i oczywiście B.

Edit 2: Drobny hint, bo możesz oczywiście posłać dane do drukarki dość szybko:

W=320
DIM B$(W): B$(W)=CHR$(0)
X=USR(R,A0,A1,A2,A3,A4,A5,A6,A7,ADR(B$),W)
LPRINT B$;

LPRINT otwiera i zamyka każdorazowo kanał drukarki. Nie wiem jak działa ten Microprint - możliwe, że wystąpi problem z drukowaniem bajtu EOL (155 w trybie druku tekstu pewnie zamieniany jest na CRLF czyli 13,10), choć powinien rozpoznać że jest w trybie drukowania grafiki po komendach ESC. Na pewno bezpiecznie przestawić go po wszystkim z powrotem w tryb tekstowy.

Covox dostępny jest w SimpleStereo by Candle. Nie da się go wykryć w żaden sposób i w żadnym dostępnym rozszerzeniu.

Edit: I zdaje się jeszcze był uCovox by Pajero.

Gratulacje Y!

A tam offtopic - w temacie jest.
Pattern dla instrumentów chipowych ma 16 pozycji, ale dla sampli już 32. Sample są odpalane 2x częściej niż instrumenty chipowe więc obydwa rodzaje patternów idą równo. No i player gra tylko na VBLK (kanał sampla zajmuje zawsze 4 generator POKEY-a i gra co drugą linię rastra czyli 7.778 kHz).
Liczba patternów chipowych to 128, ale samplowych nie wiedzieć czemu tylko 64. Instrumentów można mieć 32, sampli 16.
W instrukcji są nieścisłości, ale i tak lepsza taka niż żadna :)
Nie wiem jeszcze jak są generowane brzmienia chipowe (legendarny sinus i piła), ale to się pewnie z czasem wyjaśni.