Sorry, but that's authoritative bunch of crap and fortunately you're not the one to tell anyone how to call it. Call it whatever you like yourself and that's your only right on the matter.
You mentioned Amiga and ST, for which faster CPU turbo-cards that add RAM exist literally since ALWAYS and their users have no problem to call A500 with 32-bit 020/030 CPU or A1200 with 030/040/060 an Amiga. The same goes for ST with PAK030 or TerribleFire or even C64 with SuperCPU.

Yes, it can - ADDITIONALLY.
How biased point of view you have... Imagine it can do things XE always does, TOO (and FOREMOST, otherwise no one would be interested in such new machine).
It's called BACKWARD COMPATIBILITY and applies to upgraded Amiga, ST, PC, too, unless someone really intends to exploit hardware differences to create incompatible software.
And even VBXE is just a GFX card, adding new modes, keeping old ones and anyone can still use original software via it's own or original Atari video-output.

So yeah, as long it's Atari XE motherboard (not some FPGA), original GFX/MSX capabilities stay there (which actually define our beloved computer), the OS is compatible and runs XE software, I will call it XE machine with turbo-card and more RAM, just like other platforms do.
And no, personally I even don't own Rapidus turbo-card.

czy admin moglby wydzielic do osobnego watku posty z egzystencjalnymi problem forumowiczow? dziekuje.

Doslownie w tej chwili dopiero zostal uzgodniony nowy zestaw elementow w grze - przez ten rok pojawily sie co najmniej dwie ciekawe gry mobilne z podobnymi zasadami (nadal nie ma takiej ktora mialaby wszystkie zasady z GW) i zeby dodac pomysly na uklady z tych gier trzeba bylo rozszerzyc zestawy.

:D

It should be fixed for public (i.e. buyers) not for XXL, in my opinion ;)

On the other hand, if this problem appear only with deliberately written software ment NOT to work on U1MB (which is I presume is developmental anyway), then it is also unproffesional (for the game ment to be released on market, not for demo production of any kind).

So again, fault and stubbornness lies on both sides.

Ciekawe czy tak samo reagowaliby plujacy jadem szanowni uzytkownicy gdyby firmowe oprogramowanie sprzedawane w latach '80 zachowywalo sie na tej modyfikacji tak samo jak GW... no tak, szanowni uzytkownicy nie uzywaja oryginalow ;-)

@laoo: uwazam to za trolling. ale jesli faktycznie nie wiesz... napisz @.

To są peryferia, nie wpływają na działanie jednostki centralnej, nie zmieniają sposobu adresowania pamięci... poza tym standardowo mam je odłączone. W każdej chwili mogę je podłączać lub odłączać w/g potrzeb. Można by przyjąć, że ich sterowniki mogą się gryźć z niektórymi całodyskowymi grami, ale jak przy starcie włożę taką bootowalną dyskietkę, to sterowniki od US czy NUB się nie załadują i te urządzenia tak jakby nie istniały, więc nawet nie musiałbym ich odłączać (gdybym je miał podłączone). Poza tym te urządzenia dość wiernie emulują istniejący w czasach świetności ST sprzęt (zwłaszcza Gotek), więc z punktu widzenia systemu nie są czymś nowym. U1MB zastępuję MMU i EMMU, ale nie robi tego wiernie, gdyż ma błąd (ok, niech będzie - uproszczenie) w mapowaniu pewnych obszarów pamięci. Poza jednym zatrzaskiem w EMMU, to dwa proste układy kombinacyjne... więc najwyraźniej autorzy U1MB zmienili funkcje logiczne, które te układy realizują, pewnie by oszczędzić trochę jednostek logicznych w CPLD.

Ok, that's your point of view, my point of view is that, these are only XE-compatible machines. The point is - bug in U1MB changes memory mapping, so it somehow breaks the compatibility. It also replaces one of the crucial core logic elements (the memory mapper - MMU and EMMU chips) on the XE motherboard with the (not-so-compatible) CPLD implementation. VBXE runs aside stock chips, and can be completely disabled. Furia card for A600 makes it almost A1200 (except AGA) compatible...

tylko ze to nie jest gdybanie :-) to stan faktyczny :-) nie masz tego swiadomosci podobnie jak Pablozp bo nie uzywasz oryginalow z lat 80 :-)

ja mam same oryginały i używam

Takie coś mi przyszło jeszcze do głowy. Wyobraźcie sobie analogiczną sytuację w której ATI robi kartę graficzną, która zawiera błąd, który da się naprawić patchem (pomijam trudność, o której wspomniał jazzcat), ale tego nie robi. Z drugiej strony twórcy Cyberpunka 2077 tworzą (celowo? a może jest jednak jakiś powód? - bo tego do tej pory nie wiem, a jest to dość KLUCZOWA wiedza) błąd w grze który uniemożliwia uruchomienie gry na tej karcie ATI.

Obie strony mogą się nie lubić, ale umyślnie psują takim podejściem zabawę zwykłemu użytkownikowi, który chce zagrać właśnie w to i posiada taki właśnie sprzęt.

To w takim razie, dlaczego twórcy poważnych emulatorów nie polegają wyłącznie na oficjalnej specyfikacji systemu, a starają się dotrzeć do dokumentacji poszczególnych układów składowych i odtworzyć ich działanie z dokładnością co do cyklu zegara? Tutaj wszystko było podane na tacy, bo oryginalny układ MMU był układem PAL i jego równania są znane. Jakoś liczące się emulatory (nawet czysto programowe) potrafią odtwarzać to zachowanie a kod CPLD w U1MB - nie. Wiele podrobionych układów odbiega zachowaniem właśnie w nieprzewidzianych sytuacjach i jest to powszechnie wykorzystywane do odróżnienia oryginału od podróbki (swojego czasu w Windows Update wyszedł sterownik do układów FT23x, powszechnie stosowanych w wielu urządzeniach z interfejsem USB, który wykrywał podrobione układy i... je uszkadzał, było to zrobione świadomie i z premedytacją). Niestety implementacja MMU w U1MB zachowuje się właśnie jak taka marna podróbka. Montując U1MB wyrzucamy z oryginalnej płyty XE, jeden z jej kluczowych komponentów, by zastąpić go... emulatorem w CPLD, który niby działa prawidłowo, ale inaczej niż oryginał.

Nie trzeba sobie wyobrażać, takie sytuacje miały miejsce - Flight Simulator (nie działał na maszynach "zgodnych z PC", które miały BIOS od innego producenta niż IBM), Quake (źle działał na procesorach Cyrix, które były "zgodne" z x86). W tym drugim przypadku, dobra gra, wyeliminowała z rynku producenta przeciętnego sprzętu (Cyrix używał oznaczeń PR, z których wynikało, że jego procesory są dużo szybsze od procesorów Intela, a Quake chodził na nich dużo wolniej).

No to ja już wiem - tak, błąd (różnica w zachowaniu względem oryginału - jak zwał tak zwał) jest obecny bez względu na wybrany w konfiguratorze U1MB tryb emulacji rozszerzenia pamięci. Dzieje się tak dlatego, że U1MB zastępuje nie tylko EMMU, ale również MMU (większość rozszerzeń go nie ruszała, pozostawiając pierwsze 64 kB nietknięte). Różnica w działaniu dotyczy właśnie emulowanego mapera pamięci podstawowej. Mimo ogólnie dostępnych równań dla tego układu (oryginalnie to też był układ logiki programowalnej - PAL), autorzy odtworzyli jego działanie w CPLD "po swojemu". W ramach oficjalnej specyfikacji, emulowany MMU zachowuje się tak samo jak oryginał, ale już w nieujętych w dokumentacji przypadkach - działa inaczej. Niestety po zainstalowaniu U1MB oryginalny układ "wylatuje" z płyty i nawet po wyłączeniu rozszerzenia pamięci z poziomu konfiguratora, nadal używany jest emulowany układ MMU.

AMD też używalo parametru PR, oczywiście w jednym i drugim przypadku był to głównie marketing i Pentium były o wiele lepsze zarówno od AMD jak i Cyrixów.
A w przypadku Quake'a, skoro już tak wchodzimy w detale, to różnicę robiło głównie FPU jednych i drugich procesorów - Quake był bodaj pierwszą poważną grą wymagającą jednostki zmiennoprzecinkowej, a ta w Pentium daleko wyprzedzała konkurencję.
M. in. dlatego suchy benchmark samego CPU się nie przekładał na FPS w Quake ;)

Nie drąż, nie drąż chronologii "pirata" i wydania "płatnej" wersji.
W sumie skoro tak często się odwołujesz do epoki, to środowisko poprawiło już niejednego buga w grach z epoki, poprawiło więc i Twoją grę, i nie miało to nic wspólnego z łamaniem jakiegoś zabezpieczenia (no chyba, że złośliwego "zabezpieczenia" przed odpaleniem na Atari rozszerzonym o U1MB).

To nieważne, wciąż ta sama historia: GW, H2 czy inna cholera ;)