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.

Bardzo dziękuję. Niech Ci bozia w dzieciach itd.

Edit: Tutaj to jest :)

Ok. To może pamiętasz jakie dokładnie mają znaczenie bajty definicji instrumentu? Ogólne zasady edycji i nawet instrukcje przy edycji patternu pamiętam, niestety nie mogę sobie przypomnieć co oznaczały parametry w songu. Znam player do FC i wiem co robi kod, aczkolwiek mogło mi coś umknąć. Stąd chciałbym właśnie instrukcję :)

Pewnie, że bym się podzielił - skoro .cas już jest, to przeskanuję instrukcję i okładki i podeślę (ew. mogę komuś podesłać gdyby chciał to zrobić lepiej).
Dyskietka do FC jest nieco sfatygowana i jak mówiłem zagubiłem instrukcję, ale też mogę przeskanować. Dysk ma zabezpieczenie (chyba słaby sektor, albo dwa sektory o tym samym nrze na ścieżce) więc jeśli ktoś potrafi to odczytać i udostępnić jakiś obraz do skopiowania, to mogę również się podzielić :)

Zniechęcony jak sądzę.

Maczałem swoje paluchy w tym regulaminie. Ponieważ słuchałem różnych argumentów Pina postaram się wyjaśnić może niektóre kwestie, ponieważ myślę że każdy zapis regulaminowy ma swoje motywacje:

I. "Używamy tylko udokumentowanych rozkazów procesora 6502C, unikamy błędów opisanych w http://atariki.krap.pl/index.php/6502 ". Zapis ma na celu uszanowanie osób które w Atari mają zamontowany procesor inny niż fabryczny, lecz zgodny z oficjalną listą rozkazów 6502. Czy są one mniejszością, czy większością to nie ma znaczenia. Ponieważ jest nas wszystkich raczej dość mało, to chodzi po prostu o to, żeby jak największa ilość osób nie miała problemu z uruchomieniem pracy na swojej maszynie - czy to będzie fabryczne Atari, czy zmodyfikowane.

II.2. "Prace będą prezentowane w stereo. Jeśli muzyka pisana jest w mono, a tracker umożliwia pracę w stereo proszę zdublować podstawowego POKEY-a przepisując wartości w songu na drugi układ". Zapis ma na celu uszanowanie posiadaczy Atari rozszerzonego o drugi układ POKEY, jak również partyzantów, żeby na kompotach nie zastanawiać się jak tu poprzełączać audio żeby dźwięk nie poleciał z jednego głośnika, nie wysłuchiwać protestów Autorów i nie powtarzać odtwarzania.

IV. "Praca musi działać z rozszerzeniami pamięci typu CompyShop oraz Rambo". Znowu chodzi o uszanowanie posiadaczy rozszerzeń i eliminację sytuacji, że program maluje krzaki bo programista zapomniał że istnieją rozszerzenia typu Rambo.

V. "Loader plików wykonywalnych obsługuje wyłącznie ładowanie do pamięci podstawowej ($0000..$BFFF), program w postaci .XEX używający pamięci dodatkowej (CompyShop oraz Rambo) lub pamięci pod ROM-em powinien samodzielnie zatroszczyć się o inicjalizację lub przepisanie danych do takich obszarów np. w bloku inicjalizacyjnym z pamięci podstawowej". Chodzi o uszanowanie osób posiadających zamontowane różne rozszerzenia pamięci oraz (być może) VBXE i korzystających z różnych DOS-ów. Priorytety pamięci bankowanej mogą być w różnych rozwiązaniach różne, loadery mogą być różnie napisane, i nie można polegać na tym, że zapisanie w bloku pliku .XEX wartości bezpośrednio pod rejestr sprzętowy spowoduje, że ta wartość tam będzie do końca świata. Lepiej (a na pewno bezpieczniej) zapanować nad działaniami systemu i inicjalizować sobie co trzeba kawałkiem programu.

Oczywiście pominięto kwestie np. rozszerzeń Sim4MB, Axlon, VBXE, stereo z przerwaniami itp., żeby nie tworzyć epopei.

Zapisy mają na celu nie utrudnienie życie Programiście, a ułatwienie życia Użytkownikowi - w końcu nie każdy user zna się na bebechach i kodowaniu a chciałby od czasu do czasu coś fajnego zobaczyć. Nawet mając w sprzęcie rozszerzenia o których działaniu wie może tylko tyle, że dają fajne możliwości (dźwięk, obraz, szybkość).

Zwróćcie też uwagę, że wiele punktów regulaminu uwzględnia sytuacje wyjątkowe (źródła prac) i sugeruje pewne rozwiązania (stereo mono).

Atari jest komputerem o fajnej rozszerzalnej architekturze i Programista nie może go traktować, jak zamkniętą konsolę do gier bo ucierpi na tym zawsze użytkownik. Programista, jako starszy i mądrzejszy powinien zadbać o wygodę Użytkownika, bo on pisze program raz, a Użytkownik uruchamia go wiele razy.