276

Odp: Gravity Worms

_tzok_ napisał/a:

Przecież jest konfigurator... czy pomimo wyłączenia rozszerzenia pamięci z jego poziomu, nadal miesza ono z dostępem do pamięci?

też chciałbym to wiedzieć

277

Odp: Gravity Worms

_tzok_ napisał/a:

. If you like 16-bit CPUs, go for Atari ST or Amiga, or even RAPIDUS, but don't call RAPIDUS an Atari XE. It has nothing to do with Atari XE

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.

It can do things that real XE system could never do.

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.

Ostatnio edytowany przez Jacques (2020-10-09 08:45:13)

278

Odp: Gravity Worms

A mnie bardzo ciekawi jak XXL zapatruje się na sianie zapisami w rejestry powtórzone na stronie $D2?
No przecież w Atari np. IRQ można wyłączyć zapisem pod dowolny z adresów $D2xE? Czy są w GW zapisy pod $D21E, $D26E, albo powiedzmy $D2AE? A xBios której szesnastki używa do czytania z dysku? Też losuje?
Przecież będzie działać. No chyba że ma się PokeyMAXa to wtedy nie... hm...
Powtórzenia na $D2 są jakieś inne od powtórzeń na $D3?
A jakby ktoś chciał na $D3 dać jakieś inne rozszerzenie poza U1MB? Jakieś takie fajne, które też by się podobało XXLowi?
¯\\\_(ツ)\_/¯

279

Odp: Gravity Worms

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

http://atari.pl/hsc/ad.php?i=1.

280

Odp: Gravity Worms

Tak myślałem :D

281

Odp: Gravity Worms

flashjazzcat napisał/a:

I think Candle acknowledged the 'behaviour' of the hardware. You'll have to ask him why he didn't fix it in new devices. Wild guess? XXL's attitude has been so fucking obnoxious that the chance for a fix has been blown.

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.

282

Odp: Gravity Worms

tyle jest fajnych gier na atari.. po wuj wam to powalone gravity

.

283

Odp: Gravity Worms

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 @.

http://atari.pl/hsc/ad.php?i=1.

284

Odp: Gravity Worms

wszystko działa, co za problem . Co to jest GW .. nie wiem  i mama spokoj

.

285

Odp: Gravity Worms

Pin napisał/a:

odłącz od swojego ST i wyrzuć  - Goteka, UltraSatana i NetusBee, bo to nic wspólnego z Atari nie ma

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.

Jacques napisał/a:

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.

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...

Ostatnio edytowany przez _tzok_ (2020-10-09 11:45:49)

Moja kolekcja: Atari 1040STe (4MB), Atari 1040STfm (4MB, BLiTTER, AT-ONCE+), Atari 800XE (SIMM EXP 1MB), Atari 800XL (RAMBO XL 256kB), Atari 600XL (64kB), Sinclair ZX SPECTRUM+ (48kB), TIMEX Computer 2048 (48kB), Commodore A600 (2MB+4MB, HDD CF 4GB), Commodore C64C.

286

Odp: Gravity Worms

xxl napisał/a:

gdyby firmowe oprogramowanie sprzedawane w latach '80 zachowywalo sie na tej modyfikacji tak samo jak GW...

Kolejny argument xxl-style: GDYBY ktoś zaciągał się oparami absurdu jak on :D

Na szczęście większość cywilizowanego świata równała, równa i będzie równać w górę, w stronę kompatybilności i jak coś mogło działać na 400/800/XE/XL to działało, dla większego zasięgu produkcji i bazy użytkowników.
A co do gdybania: jakby rozszerzenie jakiejś firmy trzeciej stało się popularne, to świadomi tego wydawcy softu także by to uwzględnili by więcej osób nabyło ich produkt, zwłaszcza gdy wysiłek kosztowałoby zrobić tak, żeby nie działało, bo działałoby bez problemu.

xxl, masz prawo do swoich dziwactw, ale uzasadnianie tego takim kitem jest bardzo słabe.
Wolisz w ramach hobby dzielić użytkowników, trollować środowisko i ograniczać zasięg swoich produkcji, trudno, damy radę, Atari to wiele więcej niż to co robisz Ty.

Ostatnio edytowany przez Jacques (2020-10-09 11:42:17)

287

Odp: Gravity Worms

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

http://atari.pl/hsc/ad.php?i=1.

288

Odp: Gravity Worms

Nie wątpię, że w swojej manii jakimś cudem wyszukałeś jakiś prog stanowiący 0.01% całości softu Atari 8-bit z epoki, ale nie nazywaj tego "oryginałami z epoki" brzmiąc jakby to miała być większość.
Inaczej już dawno byłoby to podnoszone jako rzeczywisty problem z U1MB przez użytkowników. Problem kreujesz Ty.

Ostatnio edytowany przez Jacques (2020-10-09 11:55:58)

289

Odp: Gravity Worms

ja mam same oryginały i używam

.

290

Odp: Gravity Worms

@xxl a dlaczego nie na forum?

Ogólnie najbardziej absurdalna w tej dyskusji jest próba nazywania podejścia U1MB błędem, a używanie powtórzonych rejestrów czymś normalnym, bo jest precedens, że ktoś w latach 80-tych robił to samo.
Otóż nie. I nie róbcie kurtyzany z logiki.
Obszar adresowy, który nie jest zdefiniowany powoduje niezdefiniowane zachowanie.
KROPKA.
U1MB definiuje kilka rejestrów, a pozostałe dalej pozostawia w stanie niezdefiniowanym. To, że implementacja się zmieniła, nie ma znaczenia. Nikt tego nie zdefiniował, że tak ma być i przypadkowe działanie nie jest jakimś wytłumaczeniem, że można na tym polegać. Jak ktoś celowo używa niezdefiniowanego zachowania jest trollem, albo głąbem (trzeciej opcji nie ma) i sam sobie strzela w stopę, bo wystarczy, że następne rozszerzenie akurat użyje rejestru traktowanego jako mirror PORTB i po zawodach. Tak samo jak trollem, albo głąbem byłby ktoś, kto zakładałby, że jeden jedyny POKEY powtarza się w całej stronie $D2. No tylko, że z powodów politycznych te mirrory akurat nie są koszerne, mimo że nie ma żadnej różnicy pomiędzy mirrorami POKEYa, a mirrorami PIA.

Ostatnio edytowany przez laoo/ng (2020-10-09 12:05:37)

291

Odp: Gravity Worms

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.

292

Odp: Gravity Worms

@stRing no to ta analogia powinna wyglądać tak, że twórcy Cyberpunka sami napisaliby sobie swoje sterowniki i użyli rejestrów, które przypadkiem w starej karcie ATI działały a w nowej nie. Redzi argumentowaliby, że karta ma błąd, bo przecież w starej karcie jak użyli jakiegoś nieopisanego rejestru to działo się coś co dało się uzyskać oficjalnie, ale woleli tak (bo hehe, są przecież hakerami piszącymi własne sterowniki), a w nowej to działa zupełnie inaczej. Argumentem ATI byłoby, żeby puknęli się w głowę i używali tylko udokumentowanych rozwiązań, ale oczywiście taki argument odbijałby się od ściany...

Jak teraz wyglądałby ten spór?

293

Odp: Gravity Worms

laoo/ng napisał/a:

Otóż nie. I nie róbcie kurtyzany z logiki.
Obszar adresowy, który nie jest zdefiniowany powoduje niezdefiniowane zachowanie.
KROPKA.
U1MB definiuje kilka rejestrów, a pozostałe dalej pozostawia w stanie niezdefiniowanym. To, że implementacja się zmieniła, nie ma znaczenia. Nikt tego nie zdefiniował, że tak ma być i przypadkowe działanie nie jest jakimś wytłumaczeniem, że można na tym polegać.

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ł.

stRing napisał/a:

Wyobraźcie sobie analogiczną sytuację

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).

takron27 napisał/a:

też chciałbym to wiedzieć

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.

Ostatnio edytowany przez _tzok_ (2020-10-09 13:09:05)

Moja kolekcja: Atari 1040STe (4MB), Atari 1040STfm (4MB, BLiTTER, AT-ONCE+), Atari 800XE (SIMM EXP 1MB), Atari 800XL (RAMBO XL 256kB), Atari 600XL (64kB), Sinclair ZX SPECTRUM+ (48kB), TIMEX Computer 2048 (48kB), Commodore A600 (2MB+4MB, HDD CF 4GB), Commodore C64C.

294

Odp: Gravity Worms

laoo/ng napisał/a:

Obszar adresowy, który nie jest zdefiniowany powoduje niezdefiniowane zachowanie.
KROPKA.

wychodzisz z blednego zalozenia i dochodzisz do blednych wnioskow. w literaturze jest dokladnie napisane jak ten obszar jest zdefiniowany.

http://atari.pl/hsc/ad.php?i=1.

295

Odp: Gravity Worms

_tzok_ napisał/a:

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.

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 ;)

Ostatnio edytowany przez Jacques (2020-10-09 12:50:02)

296

Odp: Gravity Worms

Jacques napisał/a:

Inaczej już dawno byłoby to podnoszone jako rzeczywisty problem z U1MB przez użytkowników.

odpowiedza jednego z "zainteresowanych" bylo: uzyj pirata to bedzie dzialac.

http://atari.pl/hsc/ad.php?i=1.

297

Odp: Gravity Worms

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).

Ostatnio edytowany przez Jacques (2020-10-09 12:58:18)

298

Odp: Gravity Worms

zakreciles sie :-) nie chodzi o GW :D

http://atari.pl/hsc/ad.php?i=1.

299

Odp: Gravity Worms

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

300

Odp: Gravity Worms

tez pudlo :-) przeczytaj post 287 :-) nie moje oprogramowanie.

http://atari.pl/hsc/ad.php?i=1.