651

(410 odpowiedzi, napisanych Fabryka - 8bit)

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.

652

(410 odpowiedzi, napisanych Fabryka - 8bit)

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.

653

(410 odpowiedzi, napisanych Fabryka - 8bit)

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

654

(410 odpowiedzi, napisanych Fabryka - 8bit)

I've been confronted on the Forum with Lotharek and Candle and I found them reacting quite aggressively to any criticism of their products, and acting like they were the smartest and greatest people on the World, and everyone should love and adore them, and be thankful for their products. On the other hand, XXL's replies, in general, seem to be more calm and cultural.

flashjazzcat napisał/a:

He advocates illegal OS entry points, seems to consider 'NEWDEV' an aftermarket invention, and has an ethical objection to 16-bit CPUs.

This is called purism, I understand and respect that. This is retro stuff. The hardware is what it was back in the '80s. We can, and should, explore its abilities in software, but keep the hardware in its original form. 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, except it uses its case, keyboard, and a (modified) system software. It can do things that real XE system could never do. It is really great, but it is no longer an Atari XE.

655

(410 odpowiedzi, napisanych Fabryka - 8bit)

flashjazzcat napisał/a:

Simple question for you: which is easier? Distributing a JED file and asking every U1MB owner to purchase a Xilinx platform cable, download the Lab Tools software, make a suitable patch cable for the 2mm JTAG header, and flash the CPLD of their U1MB, or XXL changing his damn game?

Life is not simple... first step is to admit, that there is a bug. Next step is to correct a bug, and sell new units with a corrected firmware. Final (but optional) step is to offer a firmware upgrade for existing users (may be even paid, or may be DIY). This maybe this is not simple, but is fair. So do you prefer simple, or fair solutions? I have no doubts that, as the bug is known, it should be corrected. I'm aware that manufacturer/distributor may be afraid to admit, that there is a bug, because it could mean, that he had to correct it on his cost (at least for units, which are still within the warranty period) - by replacing or reprogramming the units.

XXL seems to be a little too proud to give up, but so do the U1MB developers. Yet he fights for a fair treating of the Atari community, so I keep my fingers crossed for him. I'm pretty sure, if the U1MB developers would publicly acknowledge that there is a bug in the U1MB, relesed a patched/corrected firmware, and started selling units with this new firmware, XXL would release a patch for his software to work with a stock/not pached U1MB. The war would be over.

656

(410 odpowiedzi, napisanych Fabryka - 8bit)

Pin napisał/a:

Wyłączyć, czyli wyjąć na chwilkę z komputera po to, by zagrać. To dobry pomysł.

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

657

(410 odpowiedzi, napisanych Fabryka - 8bit)

Ja w tej chwili nie mam żadnej "gołej" atarynki, ale też w żadnej nie mam U1MB. Najmocniejsza to 800XE z 1MB RAM (przełączane 1MB RAMBO/ 512kB Compy Shop) i QMEG OS. Rozszerzenie proste, tanie i kompatybilne. Wszystkie atarynki leżą w szafie, więc i tak, jak chcę w coś zagrać, muszę sięgnąć do szafy i którąś wyciągnąć.

Upór ze strony XXL jest czysto ideologiczny. W końcu jego MAP-RAM też stockowym rozwiązaniem nie jest. Dlatego uważam, że chodzi wyłącznie o to, by developerzy U1MB otwarcie przyznali, że ich produkt posiada błąd w firmware. Oni natomiast idą w zaparte, że to nie jest błąd, tylko założenie projektowe, więc nie będą go poprawiać (czyli klasyczne "nie bo nie").

U1MB nie jest potrzebny do gier XXL'a, bo wszystkie chodzą na 64kB. U1MB można wyłączyć i nie wiem, czy wtedy nadal ten błąd się ujawnia. Jeśli tak, to już bardzo niefajnie i nie przemówi do mnie żadne tłumacze, że tak miało być. Kiedy jest aktywne, niech sobie robi co chce, ale kiedy jest wyłączone, ma być tak, jakby go nie było.

658

(410 odpowiedzi, napisanych Fabryka - 8bit)

Don't you think, that both sides of the conflict are equally stubborn (you will probably deny, because you are one of the sides)? I don't think XXL even cares about correcting the bug, he just wants U1MB developers to admit, that it is a bug. You say "not worth bothering for one piece of software", so I bet he will release more software, which deliberately won't work with U1MB... just for his satisfaction, and to eradicate the argument about "one piece of software".

659

(17 odpowiedzi, napisanych Software, Gry - 16/32bit)

Pin napisał/a:

hehe, a na maluchu w publicznej i bez problemu

Jaki tam z niego "maluch". 65c816@20MHz to pełnoprawne 16 bitów.

660

(65 odpowiedzi, napisanych Fabryka - 8bit)

Mam potwierdzenie, że kartridż dotarł, dzięki!

661

(20 odpowiedzi, napisanych Sprzęt - 8bit)

Tu masz porównanie zwykłego wykończenia i z "prasowaniem":
https://obrazki.elektroda.pl/5139391200_1601648705_thumb.jpg

662

(20 odpowiedzi, napisanych Sprzęt - 8bit)

Czym to sliceujesz? Jeśli CURA to możesz włączyć ironing górnej warstwy. Z drugiej strony, skoro i tak kleisz z kawałków, dlaczego nie drukujesz zewnętrznych powierzchni na buildplate? Jak weźmiesz szybę z taśmą malarską, to dostaniesz ładną fakturę, Ultrabase też daje bardzo estetyczną powierzchnię.

Czyli problem był z napięciem 12 V... bo sam zasilacz dostarcza tylko +5 V i +12 V.

664

(56 odpowiedzi, napisanych Fabryka - 16/32bit)

Żeby skorzystać z SELTOSa, trzeba uruchomić TOSa... a TOS 1.x nie ruszy nawet na 68010 (sprawdzałem).

EmuTOS w wersji 192 kB jest bardzo okrojony i oficjalnie wspiera tylko 68000, do "pełnej" wersji potrzebny jest "relokator" jak do TOS 2.x.

665

(56 odpowiedzi, napisanych Fabryka - 16/32bit)

TF skopiował nasz rodak, ale mieszkający w Niemczech i związany z PPA - dlatego nie będzie kolejnych TF dla Amigi. Do PL nie wysyła przez burdel na naszej poczcie i ginące/idące kilka miesięcy przesyłki.

666

(65 odpowiedzi, napisanych Fabryka - 8bit)

Jak zapis w grach działa prawidłowo, to mogą być dowolne kości.

667

(226 odpowiedzi, napisanych Fabryka - 8bit)

infarmotyk napisał/a:

Właśnie, jak to jest z portem SIO, czy na wszystkie linie sygnałowe możemy podawać pełne 5V?

Na Audio Input (11) raczej nie polecam, pozostałe wejścia są TTL.

668

(65 odpowiedzi, napisanych Fabryka - 8bit)

Jak dla mnie to mogą być nawet czyste kości. Mam programator, mogę sobie zaprogramować, co mi będzie akurat potrzebne. Także ten SH to raczej tylko tak testowo.

669

(65 odpowiedzi, napisanych Fabryka - 8bit)

A co tam... też sobie wezmę. Możesz oszczędzić na przesyłce i wysłać oba do Rastana.

1. pancio.net - 1szt
2. DaruG - 1szt
3. Pawel - 1szt, Space Harrier
4. Sikor - 1szt, Space Harrier poproszę smile
5. perinoid - 1szt.
6. MGor - 1szt, Space Harrier to dobry pomysł smile
7. Montezuma - 1 szt.
8. lopez - z zaprogramowanym Space Harrier'em - szczegóły PW
9. Yezy - 1szt. szczegóły PW -DOWOLNE KOŚCI
10. Rastan - 1 szt., Space Harrier
11. _tzok_- 1 szt., Space Harrier

670

(28 odpowiedzi, napisanych Sprzęt - 8bit)

Według opisu na Githubie - poprawił.

671

(410 odpowiedzi, napisanych Fabryka - 8bit)

Jak chcę nowoczesności to wolę siąść przy współczesnym kompie z Core i9 albo Ryzenem...
Nie mam też nic przeciwko współczesnym akcesoriom zewnętrznym, sam używam SDriveMAX. Z punktu widzenia Atari jest to stacja 1050 i zawsze można go odłączyć i podłączyć oryginalną stację lub magnetofon. Sam się przekonałem, że "ekipa" od U1MB nie jest zbyt przyjazna dla ludzi i trochę rozumiem XXLa. Uważam, że ma pełne prawo do takiej decyzji.

Jacques napisał/a:

Chyba bardziej istotna jest wszechstronność i bogata lista ficzerów niż cena.

Jeśli te ficzery są wykorzystywane przez 0,1% istniejącego oprogramowania, to mi na nich specjalnie nie zależy. Rozszerzenie, które mam w XE też jest "wszechstronne", bo można je albo całkowicie wyłączyć, albo może emulować 2 najpopularniejsze rozszerzenia z epoki w maksymalnej specyfikacji. Niczego więcej od rozszerzenia pamięci nie oczekuję. A jeśli przy tym mieści się pod fabrycznymi ekranami, nie trzeba wiercić żadnych dziur w obudowie/płycie, żeby je przykręcić i kosztowało 1/3 ceny U1MB, to już nie było się nad czym zastanawiać.

672

(410 odpowiedzi, napisanych Fabryka - 8bit)

Jacques napisał/a:

Dyktatorskim zapędom nie wolno ustępować

Zgoda, ale sęk w tym, że dyktatorskie zapędy są po obu stronach. Jedna strona nie chce się przyznać, że to błąd, a druga za wszelką cenę próbuje to udowodnić.

Jacques napisał/a:

Na szczęście widać także na Atari Age, gdzie U1MB czy Incognito są bardzo popularne

Są, bo dla użytkowników z UK czy USA ceny tych dodatków są bardziej przystępne. Ja jestem zdania, że należy się trzymać oryginału lub czegoś, co go wiernie emuluje. Jeśli już pakować rozszerzenie pamięci, to coś, co mogło istnieć "w epoce". Także, dla mnie fajnie że U1MB jest, ale ja go sobie nie kupię (a mimo to mam 1 MB w 800XE).

673

(410 odpowiedzi, napisanych Fabryka - 8bit)

pancio.net napisał/a:

Dziękuję za wyjaśnienia... A po cóż gra "tyka' drugą połówkę strony $D3? Bo chyba nie po to by pójść w maliny?

No niestety właśnie po to, albo bardziej dyplomatycznie, po to, aby skłonić autora/ów U1MB do poprawy buga, o którym oni twierdzą, że nie jest bugiem tylko ficzerem ;) Zwykła próba sił - kto na tym więcej straci. Czy więcej klientów ma oprogramowanie XXLa czy U1MB.

674

(45 odpowiedzi, napisanych Sprzęt - 8bit)

Jeden z pull-upów tam jest jakby nie z tej strony...

675

(226 odpowiedzi, napisanych Fabryka - 8bit)

...ja bym to flashował tym:
https://www.espressif.com/sites/default … v3.8.5.zip
ew. tym:
https://github.com/nodemcu/nodemcu-flasher
Tylko trzeba znać layout Flasha, a ja nie mam FujiNet'a i jakoś nie bardzo zamierzam mieć (SDriveMAX mi w 100% wystarcza i obsługuje Turbo), więc się tym za bardzo nie interesowałem.

Z tego co widzę, to flasher do FujiNet bazuje na Pythonowym skrypcie:
https://github.com/marcelstoer/nodemcu-pyflasher
...i pewnie brakuje mu jakiejś biblioteki, albo ma ją w niewłaściwej wersji.