Oczywiście, xxl wins, flawless trollity.

Devices like PokeyMAX are used to resurrect old hardware in case that the piece of original hardware have failed, and it is impossible to buy a new one. I could justify that. Yet U1MB designers decided to replace a good and working base memory mapper, with their own replacement. What is even worse, their replacement is not a recreation of the original MMU chip (which logic equations are well known, as it was a PAL chip originally), but acts like a poorly written emulator - it replicates behavior of the original hardware only up to the official specs, but beyond it, behaves differently. The MMU chip actually has nothing to do with the memory expansion. It is used only for base memory (it is strange they bother to implement it as U1MB doesn't replace the base memory), and all memory extensions I know, leave it untouched. So by installing U1MB, you basically throw away good, working, original chip, and replace it with an imperfect hardware emulator. I guess it was done only for a convenient way of installing the U1MB into the MMU socket, but instead of moving the original MMU onto the U1MB board, they decided to throw it away, and recreate it in CPLD.

Masz to jako bonus, na pocieszenie... ale podstawowe (reklamowane) zastosowanie to:

Wskaż proszę tę oficjalną literaturę od Atari, która specyfikuje adres rejestrów PIA w zakresie

%11010011******00 - %11010011******11

przy jednoczesnym określeniu adresów POKEYa w zakresie

%1101001000000000 - %1101001000001111

gdzie * to bit o dowolne wartości?

Jeżeli jednak owa literatura dokumentuje istnienie mirrorów rejestrów POKEY, to dlaczego Twoje oprogramowanie nie korzysta z tego dobrodziejstwa? Skąd ta wybiórczość i nie korzystanie z pełnych możliwości Atari?

Więc dyskutujemy na podstawie dokumentu, który stwierdza, że:

oraz:

Przy jednoczesnym stwierdzeniu, że:

Czyli mirrory PIA są zawsze, mirrory POKEY są, ale tylko podczas pisania tej książki (później to już nie wiadomo, bo książka tego nie określa), a mirrory GTIA co prawda istnieją, ale nie należy ich używać, bo kto wie jakie będzie ich przeznaczenie w przyszłości.

Żelazna konsekwencja.

Jednocześnie żelazna logika podpierania nimi swojego postępowania.

Nie mam więcej pytań.

@laoo, ale jest jeszcze inny problem - a raczej ten sam, tylko nie wiem dlaczego nikt nie rozwija tego wątku w tym kierunku, bo to jest na prawdę istotne. Druga połowa strony rejestrów powtórzonych portu B jest niewłaściwie obsługiwana przez U1MB, a w istocie te adresy są "zarezerwowane do późniejszych zastosowań" przez U1MB, czyli krótko mówiąc zablokowane do użycia zarówno przez software (na co wskazuje xxl w swej krucjacie), jak również przez hardware (chyba że tak nie jest?). Na podstawie opisów całej sytuacji związanej z tym bugiem, mam poważne obawy, że gdybyśmy chcieli zrobić sobie teraz jakieś rozszerzenie nowe do Atari, które chcielibyśmy adresować w drugiej połowie strony rejestrów powtórzonych portu B (bo przecież są niewykorzystane), to tak samo jak się sypie komputer z U1MB po odpaleniu GW, tak samo będzie się prawdopodobnie sypał po podłaczeniu takiego rozszerzenia i próby używania go w takim komputerze, w którym zainstalowano zabugowane U1MB. Jest tak, czy tak nie jest? Jeżeli jest tak, to jak można tego nie poprawić w U1MB i to z powodu focha, bo xxl robi złośliwe programy i na złość jemu nie bo nie?

Bardzo możliwe, że to właśnie mają na myśli autorzy U1MB pisząc o tych adresach, że są zarezerwowane pod przyszłe cele. Rozchodzi się wtedy jednak o to, że ta rezerwacja jest z góry grabieżą przestrzeni adresowej, bo nie można teraz skonstruować jakiegoś rozszerzenia, które ma być niezależne od U1MB i działać na wszystkich komputerach bez względu na to czy mają U1MB.
Załóżmy że chciałbym zrobić, nie wiem, np. kartę dźwiękową, którą chciałbym umieścić w przestrzeni adresowej drugiej połowy strony portu B, ponieważ nie korzysta z tego obszaru żadne inne rozszerzenie na dzień dzisiejszy. Takie rozszerzenie nie zadziała prawdopodobnie na komputerach z U1MB i mamy problem. Nie przekonuje mnie koncepcja dogadywania się wtedy z U1MB, że łaskawie dopuszczą rozszerzenie lub nie, i że będzie można je konfigurować z poziomu U1MB. Oczywiście taka konfiguracja jako dodatek była by fajna i urządzenie można by skonstruować na tyle otwarte, żeby umiało współpracować z konfiguratorem U1MB, jednak to jest rzecz dodatkowa, a nie może być tak, że urządzenie nie będzie działało jeśli U1MB łaskawie na to nie pozwoli.

mylisz sie, caly ten "spor" jest tylko medialny. nakrecany przez takich troche niezorientowanch ludzi jak flashjazzcat albo troli typu Jacques. Ani ja i zaloze sie Candle tez nie uwaza tego za problem :-)

swiat kreci sie dalej :-)

W programie do tworzenia obrazów cartridży  Maxflash Cartridge Studio, w menu kontekstowym
jest opcja: "hacks-->portb".
..tak się zastanawiam czy by to coś nie pomogło w temacie xxl'owych gierek i U1MB.
:- )

nie wiem czy nie było by dobrym pomysłem zrobić taki marketingowy zabieg i np. nie dorzucić do pudełka z grą
naklejeczki z obrazkiem, na którym robak pożera U1MB.
..ewentualnie U1MB przygniata robaka.

... z 10 sztuk pewnie pójdzie :)