Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
VIII. Basque Tournament of Atari 2600 Kolejna relacja, wśród otrzymywanych od naszego przyjaciela Egoitza z Kraju Basków.
Przezroczysta obudowa dla Atari 800XL Rusza przedsprzedaż wyjątkowej, przezroczystej obudowy do komputera Atari 800XL!
RECOIL 6.4.5 RECOIL to przeglądarka retro plików graficznych, obsługująca ponad 550 formatów, dostępna na różnych systemach operacyjnych, z regularnymi aktualizacjami.
ABBUC Software 2024 - wyniki Ukazały się wyniki tegorocznego ABBUC Software Competition
atari.area forum » Posty przez seban
Hej!
No wersja powinna być widoczna po uruchomieniu czy to micro-loadera czy to KOS-a, np:
Microloader w wersji 2.7 prezentuje się tak:
a KOS w wersji np. 2.0, tak:
A KOS w starszej wersji, np. tak:
EDIT: Możliwe też jest że w wersji cart-a którą masz nie ma informacji o wersjach, bo ktoś usunął te informacje.
poza tym dlaczego mam ograniczac rozwoj w tym kierunku... ktos bedzie chcial to uzyje nie to nie i nic sie nie stanie ;)
no jak to dlaczego? ;-)
^^^ src: xkcd
A tak na serio, Ja Ci niczego nie bronię ;) i nie chcę ograniczać niczego ani nikogo... z tyłu głowy miałem po prostu myśl że można osiągnąć to co chcesz w sposób nie wymagający zmiana formatu AtariDOS binary. Ale jeżeli tak jak proponujesz jest Ci wygodniej/lepiej/fajniej/bo tak, etc. to mi nic do tego ... :) XBIOS to Twoje dzieło i będzie podążało w kierunku w którym zechcesz :)
no tak. ale w przypadku np. SuperPacker by Jiri, to dekompresor jest tylko raz osadzony (na początku pliku) a potem tylko małe segmenty znanych zawierające konf. dekompresora dla danego segmentu i segmenty init wywołujące procedurę dekompresującą. Pewnie tak samo jest w przypadku LZ4 i SuperPacker by TeBe, ale już w przypadku użycia EXO (o ile dobrze pamiętam) to dekompresor jest dołączany do każdego segmentu danych. I zapewne wynika to ze specyficznych wymagań exomizera, nie mówię że nie dało by się inaczej tego zrobić, ale pewnie tak było szybciej/prościej, etc. Trzeba by zapytać TeBe.
Dołączanie depackera do loadera, nie wydaje mi się dobrym pomysłem... uwiązujesz loader do konkretnych wersji programów kompresujących czy depackerów, etc. Coś się zmieni w LZ4 czy EXO i zaraz będzie problem że XBIOS w takiej to a takiej wersji nie odczytuje poprawnie plików przygotowanych przez LZ4 v.131321 bo musi być LZ4 v.131313 ... a do kompletu o ile dobrze zrozumiałem tworzysz "nowy" format pliku, niezgodny z AtariDOS binary file. Przecież żaden loader nie odczyta segmentu typu $xxxx-$0000, no chyba że ktoś będzie pisał dedykowany loader do tego typu plików.
No chyba że właśnie taki masz zamiar, tzn. przygotować taki hermetycznie zamknięty system/format pliku, który jeżeli zostanie zastosowany w danej produkcji, to uwiąże ją raz na zawsze do Twojego rozwiązania. Jeżeli takie ma być założenie, to możesz robić oczywiście co zechcesz i osoby decydujące się na Twoje rozwiązanie też będą świadome tego. Dla części osób będzie to wada, dla części osób zaleta. Tutaj zapewne będzie tyle opinii ilu użytkowników.
Niestety nie jestem osobą która będzie w tym przypadku będzie mogła zachować jakąś sensowną neutralność wypowiedzi i nie bardzo umiem tutaj stanąć po jakiejś stronie, bo sami jako Slight robiliśmy produkcje "cało dyskowe" w formacie "żadnym" i uwiązanym do loadera znajdującego się na dysku, czy mechanizmów w nim zaszytych. Oczywiście wtedy wydawało się nam że to jedynie słuszna droga... bo i można sobie robić co chcesz na dysku, czytać jak Ci się podoba... i ograniczyć wpływ czynników zewnętrznych, takich jak rodzaj DOS-a czy systemu z którego nasza produkcja zostanie uruchomiona. Wtedy wydawało nam się to sensownym rozwiązaniem, szczególne gdy działo się coś podczas wczytywania... człowiek nie musiał wnikać co się dzieje pod spodem i jakie figle spłata DOS pracujący niżej.... wszystko było w naszych rekach, nawet system operacyjny był wtedy dla nas złem. W tym samym okresie była też druga strona barykady, która nie przejmowała się ładowaniem z dyskietki poszczególnych efektów czy części... nie przejmowano się loaderem, tylko korzystano z dobrodziejstw systemu operacyjnego czy to SIO czy CIO, a nawet i DOS-a... ładowano wszystko do dodatkowej pamięci i już po załadowaniu całej binarki w odpowiednie miejsca daną produkcję czy program odpalało się tylko z RAM nie przejmując się również tym co siedziało nisko w pamięci.
Jeżeli takie demo czy produkcja było w formacie plikowym to załadować się to dało ze wszystkiego właściwie, jedyne ograniczenie było takie że o ile same efekty nie wymagały dodatkowej pamięci, to EXT RAM był wykorzystany jako swego rodzaju RAM DYSK, nie przeszkadzał już żaden OS czy kosmicznie wolne czasy dostępu do danych z dyskietki. Cześć ludzi posiadających wtedy jakieś stacje równoległe (np. Karin MAXI drive) czy HDD mogła takie produkcja ładować nawet spod DOS-a. Prędkość ładowania produkcji z takich urządzeń była nieporównywalnie wyższa.
Patrząc na produkcję z tamtych czasów, każdy robił jak chciał i jak mu było wygodniej. My jako Slight, mieliśmy jakiegoś świra na punkcie pamięci i chcieliśmy aby nasze produkcje dało się uruchomić na komputerze z 64KB RAM. Poza tym dodatkową pamięć wykorzystywaliśmy podczas tworzenia do innych celów (albo jako ramdysk, albo jako przestrzeń w której Freezer zapisywał aktualny stan maszyny). Np. kompilowaliśmy wszystko do RAM-u na "żywca" z pod QA. Przed uruchomieniem efektu (który niszczył całą pamięć, a więc samo źródło, DOS-a i wszystko co się dało jeszcze zadeptać ;] ) wykonywało się "save state" maszyny z poziomu freezer-a do EXT RAM. Po uruchomieniu i stwierdzeniu gdzie są błędy i co trzeba poprawić odzyskiwało się stan maszyny z punktu ostatniego "zamrożenia" i pisało się kod dalej. Takie rozwiązanie powodowało że 64KB pamięci podstawowej stało się dla nas jakby domyślnym środowiskiem w którym będą uruchamiane nasze produkcje.
Jak więc widzisz trudno mi ocenić Twoje rozwiązanie w dobie obecnych "trendów" panujących na scenie, bo purystą i świętoszkiem nie byłem i orałem cały RAM łącznie z OS-em czy DOS-em ;) Czy dziś patrząc na to wszystko zrobiłbym to inaczej... pewnie tak... ale wtedy pewnie nie powstałoby Bitter Reality czy Overmind w takim kształcie w jakim powstały. A że obecnie ciężko je uruchomić i są produkcjami które stwarzają problemy z uruchomieniem... bo trzeba użyć SIO2PC albo rzeczywistej dyskietki i stacji dysków, i do kompletu nie da się tego uruchomić z SIDE czy HDD, etc. takie są koszty postępu chyba... chociaż wydaje mi się że i ten problem jest trochę sztucznie wygenerowany przez nowo zaprojektowany hardware, w którym pominięto możliwość rozwiązania tej "niekompatybilności", tzn. sądzę że na rzecz tego że te 1% produkcji,które nie ruszą na tym sprzęcie po prostu zignorowano możliwość rozwiązania tego problemu.
Tyle że to to nie był jakiś skomplikowany problem do rozwiązania i zapewne jest już rozwiązany jest od "n" lat, przez różnych ludzi i zapewne nie tylko w mojej szufladzie. Ale sprzęt dziś projektuje się tak aby był tani i mało problematyczny w produkcji... bo po co dodatkowe gniazdo, wtyczka, czy kawałek kodu, który będzie rzadko wykorzystany :P Na rzecz pełnej zgodności z przeszłością w i celu zwiększenia prostoty i komfortu używania nowych urządzeń, zrezygnowano z ciągnięcia za sobą historycznego ogona w postaci SIO.
exomizer ma pewnie założenia odgórne związane z platformą dla której powstał jako pierwszy, czyli C64. Jeżeli jest z nim jakiś problem, to sądzę że trzeba by porozmawiać z TeBe celem jego rozwiązania. Nie sądzę aby jakimś problemem było dekompresowanie danych spakowanych EXO podczas ładowania (via INIT). Być może trzeba przeorganizować tylko dane trochę (bo być może exomizer /nie sprawdzałem/ depakuje dane od końca, tak jak większość cruncherów z C64/C128 i stąd wynikają pewne ograniczenia).
Były czasy kiedy używało się wielu różnych programów kompresujących z różnych platform (C64, Amiga, Atari ST) i dekompresowało się wszystko w locie podczas wczytywania... jeden z przykładów. Binarka spakowana różnymi cruncherami/packerami, w tym: PowerPacker (Amgia), Fast Cruel (C64), Faces Exploding Cruncher (C64), X-Rated Power Cruncher (C64). Część danych dekompresuje się w locie podczas wczytywania. Pozostałe wtedy kiedy są potrzebne już po wczytaniu. Kod depackerów z C64 przeniesiony 1:1 z minimalnymi modyfikacjami. Do Amigowskiego Power Packer-a zastosowano dedykowany autorski dekompresor. Wszystko zawarte w tej binarce, która załaduje się pewnie z 99% dostępnych loaderów/inicjalizerów, a pewnie i nawet DOS-a o niskim MEMLO.
czy spakowane pliki binarne do ktorych dodawany jest dekompresor maja ograniczenia dotyczace adresow init i run? przykladowo - moze byc wieloblokowy plik binarny z kilkoma initami?
Jeżeli loader jest dobrze napisany i przetwarza dane strumieniowo, to takie ograniczenie nie ma prawa mieć miejsca. Nie spotkałem loadera który nakładałby ograniczenia na ilość segmentów INIT. Wiele segmentów RUN nie ma sensu, bo ważny będzie tylko ostatni.
czy mozna czesciowo pakowac taki plik binarny?
A dlaczego miałoby tak nie być? Przykładowym narzędziem umożliwiającym takie coś jest chociażby Super Packer Jiriego Bernaseka. Z dzisiejszych narzędzi to oczywiście Super Packer od TeBe.
no jest już... w tym wątku do pobrania: http://atariage.com/forums/topic/285157 … ?p=4188238
Plik który udostępniłeś bez problemu wczytuje się i działa pod Altirra 3.10. Plik jest niestandardowy nie wiem czy w jakiś sposób "zabezpieczony" przed kopiowaniem i jest zabezpieczony przed kopiowaniem, dwa pierwsze bloki są standardowe i zawierają loader, który uruchamia się po owych dwóch pierwszych rekordach i przejmuje dalsze ładowanie gry. Jedyne co musisz zrobić aby gra się poprawnie wczytała pod emulatorem to wyłączyć "CIO patch" dla "C:" i wczytywać to wszystko w rzeczywistym tempie :)
UPDATE: szybko rzuciłem okiem na loader, wychodzi na to że po pierwszych dwóch rekordach loader oczekuje określony stan na linii DATA_IN odczekuje chwile a potem przechodzi do ładowania rekord po rekordzie dalszej części pliku, który jest już zwykłym plikiem w formacie binarnym (Atari DOS).
jak skonwertuje się plik CAS który dołączyłeś na format A8CAS-HEX, to widać że po dwóch pierwszych rekordach jest krótki blok FSK, właściwie to zawiera on tylko pisk (być może jest to tylko sygnał SPACE nadany na DATA_OUT przed następnymi rekordami) ... kurczę blade... ja już chyba gdzieś ten kod widziałem (loadera) ... tylko nie mogę sobie przypomnieć gdzie... jak mnie "oświeci" to nie omieszkam poinformować ;-)
A8CAS-HEX
FUJI
baud 00738
data 21021 55 55 fc 00 01 00 07 50 e4 a2 00 bd 00 04 9d 80 07 e8 10 f7 86 3d ad 0f d2 29 10 d0 f9 a9 06 8d 1c 02 ad 0f d2 29 10 f0 f9 ad 1c 02 d0 e8 20 9d 07 30 65 85 2c 20 9d 07 85 2d 25 2c c9 ff f0 ee 20 9d 07 85 2e 20 9d 07 85 2f a9 ae 8d e2 02 a9 07 8d e3 02 a5 2e c5 2c a5 2f e5 2d 90 10 20 9d 07 30 4e 88 91 2c e6 2c d0 ea e6 2d d0 e6 ad e2 02 c9 ae d0 07 ad e3 02 c9 07 f0 b2 a9 3c 8d 02 d3 20 92 04 ; standard record; length=132, checksum=04 OK
data 00268 55 55 fc 07 a9 34 8d 02 d3 a9 30 8d 1c 02 ad 1c 02 d0 fb f0 99 6c e2 02 a9 3c 8d 02 d3 6c e0 02 a4 3d cc 8a 02 90 03 4c 7a e4 b9 00 04 e6 3d a0 01 60 f3 36 54 6c 9a c1 04 71 76 b3 d5 13 8d af d7 f8 3d b7 d9 22 48 98 c1 f4 12 23 2d 39 53 61 75 89 8b 8d 8f 91 93 95 97 99 9b 9d 9f a1 a3 a5 a7 a9 ab ad af b1 b3 b5 b7 b9 94 94 00 70 70 70 42 40 bc 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 af ; standard record; length=132, checksum=af OK
fsk 00032 1584 ; length=1; duration=158 ms
data 00396 55 55 fc ff ff 2f 02 2f 02 00 ff ff 00 16 fb 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a9 20 8d 08 16 8d 09 16 8d 0a 16 8d 0b 16 a9 03 8d 0f d2 a9 00 8d 08 d2 60 a2 00 bd 00 16 d0 08 e8 e0 04 d0 f6 4c 72 16 a9 00 9d 10 16 bd 00 16 38 e9 01 0a 0a 0a 3e 10 16 0a 3e 10 16 0a 3e 10 16 0a 3e 10 16 18 69 b6 9d 0c 16 bd 10 16 69 16 9d 10 16 a9 00 9d 00 16 9d 08 16 4c 34 16 a2 9c ; standard record; length=132, checksum=9c OK
data 00367 55 55 fc 00 bd 08 16 c9 20 d0 06 e8 e0 04 d0 f4 60 bd 0c 16 85 c8 bd 10 16 85 c9 a0 00 8a 0a aa b1 c8 9d 00 d2 a0 20 b1 c8 9d 01 d2 8a 4a aa bd 0c 16 18 69 01 9d 0c 16 bd 10 16 69 00 9d 10 16 fe 08 16 4c 7b 16 14 1e 28 32 3c 46 50 5a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4f 4c 4a 48 46 44 42 41 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b4 ; standard record; length=132, checksum=b4 OK@cobol: ... nie wszystko musi mieć sens i cel ;) jeżeli komuś takie coś przynosi radość i powoduje że powracają dawne wspomnienia.. to czemu nie? nawet jak to będzie zgrane coś co leży dawno w sieci... to sama chęć archiwizacji swoich dawnych zbiorów może być całkiem dobrym powodem. A może w zbiorach trafi się jakaś nietypowa/niespotykana wersja?
Dokładnie tak to wygląda. Każdy z cartów jest złożony z tego co było pod ręką, jak już nawet elektronika się jakoś zgodzi... to coś pozmieniane jest w kodzie (usunięte/zmienione napisy, dodane/odjęte jakieś funkcjonalności). Istna ruleta. Dlatego postanowiłem zgrywać i analizować wszystko nawet jak wygląda podobnie.
Hej!
Cały ten soft (przynajmniej wszystkie 3 które się uruchomiły) to oprogramowanie do tzw. "Blizzard Turbo".
Wygląda że to jest też jakaś wersja "klonowana". Widzę że część napisów jest usunięta, albo zastąpiona gwiazdkami.
tak powinien wyglądać oryginalny "Phoenix 1.0":
^^^ więcej o tym carcie w tym poście
drugi ekran w innym klonie wyglądał tak:
^^^ więcej o tym klonie w tym poście.
trzecie z ekranów który pokazałeś to też oprogramowanie to blizzarda, możesz odczytać wersje KOS i micro-loadera? Do tej pory trafiłem dwa takie klony w kolekcji uicr0bee, pisałem o nich również tu.
Jeżeli chodzi o przycisk RESET w carcie to działa on tak... uruchamiasz któryś z obrazów, wybierasz jakiś program czy loader... kod zawarty w cartridge odłącza go po przeniesieniu danego programu czy loadera do RAM... i gdybyś nie miał przycisku reset to ponowny start cartridge możliwy były tylko po wyłączeniu i ponownym włączeniu komputera. Jednak gdy naciśniesz przycisk RESET na carcie, a potem reset w komputerze to cartridge powinien się uruchomić ponownie. Bo to tak naprawdę nie jest reset komputera, tylko "reset" przerzutnika w cartridge.
I teraz jedna uwaga co do tego że w jednej pozycji masz self-test... teraz przyjrzałem się temu co masz carcie... "Phoenix 1.0 by Hurek" zajmuje 16KB. Dwa pozostałe carty po 8KB... więc wszystko by się zgadzało (32KB EPROM) ... teraz rozumiem po co te przeróbki na płytce drukowanej... to jest taki multi-cart "3 w 1". Tyle że ktoś kto wykonał sobie ten cart po najmniejszej linii oporu, czyli jedna z pozycji przełączników po prostu nie będzie działać poprawnie.
Hej!
Tak na szybko... to jest jakiś "multi cart", z jaką zawartością to nie wiem, ale są w niej 4 obrazy mniejszych cartów. Jest podobny do konstrukcji multicart-ów z oprogramowaniem dla "Turbo Blizzard".
Góra carta jest tam gdzie widzisz elementy elektroniczne i EPROM z naklejką "M". Do serii XE musisz to wkładać tak aby EPROM był widoczny i skierowany ku górze. Do serii XL, tymże EPROM-em do przodu. Czyli tak jak pisałeś: "strona ze scalakiem to góra".
Nie spotkałem się z uszkodzeniem cartridge które uszkodziłoby mi komputer. W najgorszym wypadku widziałem na ekranie śmieci, brązowy/czarny ekran po włączeniu. Po usunięciu uszkodzonego carta komputer wstawał normalnie.
Do czasu aż go nie włożysz do komputera i nie uruchomisz trudno określić zawartość. Przełącznikami określasz który "bank" cartridge ma się uruchomić.
Możemy przyjąć następującą zasadę: (L - przełącznik w lewo, P - przełącznik w prawo). Są dwa przełączniki więc:
LL - bank 0
LP - bank 1
PL - bank 2
PP - bank 3
po co są przeróbki na PCB nie wiem, być może ktoś coś poprawiał lub zmieniał konf. PCB. Nie analizowałem przebiegu ścieżek/połączeń.
Pamięć zastosowana w carcie to Intelowski B57604, czyli odpowiednik 27C256... a więc 32KB EPROM.
Dziś na warsztacie kolejny cart z serii "Blizzard", tym razem to cartridge "dwa w jednym", nazwany przez wykonawcę "Blizzard II", zapewne jest to jakiś klon lub giełdowy pirat, wskazują na to usunięte wszystkie informacje o firmie KNS, o której informacji znajdowały się w innych wersjach tego samego oprogramowania. Cartridge tak naprawdę zawiera w sobie dwa zestawy oprogramowania, wyboru oprogramowania które zostanie uruchomione dokonuje się przełącznikiem umieszczonym na obudowie cartridge-a.
Tak naprawdę catridge zawiera w swojej pamięci EPROM dwa niezależne cartridge, jeden zawiera starszy zestaw oprogramowania, czyli:
Tubro KOS
Micro Loader 2.2
Tubro Blizzard Copy
Tape Test
Skoro już dotarłem do prezentacji screen-shotów, to pozwolę sobie na małą dygresję i w związku z jednym ze screenshot-ów należą się dwa słowa wyjaśnienia... robiłem je używając emulatora Altirra w wersji 3.10 ... w tej wersji została dodana eksperymentalna obsługa systemów Turbo dla magnetofonu... sprawdziłem że emulacja działa bez problemu dla systemów z serii Turbo 2000(F) w różnych wersjach... wszystkie systemy które do odmierzania czasu impulsów używają procesora wydają się działać poprawnie.. jednak w przypadku Turbo Blizzard jest inaczej, ten system używa liczników zawartych w układzie POKEY do odmierzenia czasu i pomiaru długości impulsów... niestety pod emulatorem Altirra oprogramowanie systemu Blizzard nie działa poprawnie... a dlaczego nie działa poprawnie widać dokładnie na ostatnim zrzucie ekranu (z programu Tape Test) ... wychodzi na to że emulacja timerów POKEY-a lub czegoś z nimi związanego mocno szwankuje, sygnał pokazywany przez "Tape Test" ukazuje bardzo małą dokładność pomiaru, sygnał jest postrzępiony i niejednokrotnie przekracza wyznaczone granice dla poszczególnych długości impulsów (0,1 oraz SYNC). Oczywiście ten sam test uruchomiony na realnym sprzęcie daje bardzo spójne i precyzyjne odczyty. Wniosek... na chwilę obecną pod emulatorem Altirra 3.10 system Turbo Blizzard nie jest poprawnie obsługiwany.
Wracając do głównego tematu... drugi zestaw oprogramowania zawiera:
Tubro KOS 2.0
Micro Loader 2.7
Short KOS 1.0
Looking
Z tego zestawu programów również usunięto wszystkie informacje o autorstwie czy pochodzeniu programów (miejsca w których prawdopodobnie znajdowały się takie informacje zostały wypełnione spacjami). Wersję z informacjami o autorach/firmie jednego z sub-cartów umieszczonego w tym zestawie możemy znaleźć w tym poście o carcie: Turbo Blizzard. Jak widać w tamtej wersji widniały informacje o firmie KNS. A autor tego klona usunął informacje o autorach nawet z programu kopiującego. Wygląda na to że taka była rzeczywistość tamtych czasów... ale, ale... nie ma co dywagować, więc przechodząc już do konkretów:
1) Zawartość pamięci EPROM:
Blizzard2.bin.7z - obraz całego cartridge
Blizzard2_cart1.bin.7z - wyekstrahowany obraz zawierający oprogramowanie "Blizzard Cartridge"
Blizzard2_cart1.bin.7z - wyekstrahowany obraz zawierający oprogramowanie "Turbo Blizzard".
MD5 : adc47ce3c46d9c97ed4f3ab8c733c055
SHA256: 2faa7671b7a827b3027a22293cd9439f85a9de9fef1b1b053b05348fbf7429aa
blizzard2_cart1.bin:
MD5 : c6f1f0c5d9b1ec197c9af9f02e044454
SHA256: ecce531f1463651f96e2361b5a67a831ff3b7d814c5028cc29394e9e9c4c2516
blizzard2_cart2.bin:
MD5 : 0920fce3b154368b4e5fcacb9ccda841
SHA256: 47d7c9a6f3f60e116b1f26cd014bb60af6fca4d6ecdebccf76e0d8deccd9a4ee2) wersja XEX dająca się uruchomić spod DOS-a lub dowolnego loadera plików binarnych: Blizzard2.xex.zip
Jak już wspominałem wcześniej, ten cart to tak naprawdę dwa niezależne karty, a wyporu uruchamianego "obrazu" dokonuje się w rzeczywistości przełącznikiem... robiąc wersję XEX należało zapewnić również możliwość wyboru uruchamianego softwareu, dodałem proste menu pozwalające taki wybór uczynić:
Wyboru dokonujemy klawiszem SELECT, a zatwierdzamy go klawiszem START. W przypadku oprogramowania z pozycji #1 menu, czyli "Blizzard II", jeżeli chcemy wyłączyć BASIC należy wraz z klawiszem START przytrzymać klawisz OPTION. To nie mój wymysł, lecz autorów oprogramowania :) klawisz OPTION jest sprawdzany przy starcie obrazu cartridge i na tej podstawie podejmowana jest decyzja czy BASIC zostanie włączony (dzieje się to niezależnie od systemu operacyjnego)
3) Schemat: wektor (PDF), raster color (PNG), raster grayscale (PNG).
Jest to standardowa konstrukcja tego typu carta, mapowany jest w obszarze $A000-$BFFF, z możliwością programowego odłączenia przez dowolne odwołanie (odczyt/zapis) do dowolnej komórki z przedziału $D500-$D5FF. Układ odłączenia zrealizowano na prostym przerzutniku RS, zbudowanym z bramek NAND. Dowolne odwołanie do $D5xx powoduje aktywność sygnały ~CCTL, a co za tym idzie wyzerowanie przerzutnika i ustawienie sygnału RD5 w stan 0, co przez system i sprzęt jest postrzegane jako odłączenie cartridge. Ponowne włączenie może nastąpić gdy użytkownik wciśnie przycisk RESET umieszczony w cartridge.
Cartridge zawiera przełącznik umożliwiający zmianę staniu linii A13, a co za tym idzie wybór jednej z połówek pamięci EPROM widocznej w obszarze $A000-$BFFF, co skutkuje wyborem jednego z dwóch 8KB obszarów mapowanych w przestrzeni adresowej Atari (Pamięć EPROM ma pojemność 16KB).
Dodatkowo w cartridge zawarto sprzętowy "układ zabezpieczenia antypirackiego". identyczny z tym umieszczonym w BIG 2.0 by KNS - Blizzard Cartridge. Przejrzałem kod obu zestawów oprogramowania i nie znalazłem fragmentów kodu sprawdzających to "zabezpieczanie". Zrobiłem to jednak dość pobieżnie nie przykładając się zbytnio... potem uruchomiłem kod na emulatorze z ustawioną pułapką (breakpoint) na odczyt z obszaru $D500-$D5FF, jednak takie odwołania nie nastąpiły. Aby mieć pewność że całość działa bez owego układu (a co za tym idzie np. czy wersja XEX będzie działać poprawnie), sprawdziłem całość na realnym hardware... udało mi się wczytać różne gry z każdego z loaderów, KOS-a, i short KOS-a. Przyznam że nie testowałem zapisu, ale tą część pozostawię już osobom zainteresowanym tematem.
Co prawda zastanawia mnie sens stosowania takiego zabezpieczenia, skoro piraci/handlarze/klonerzy kopiowali również układ "zabezpieczający", ale widać robili to dla "świętego spokoju". O ile w kodzie KNS BIG 2.0, można było znaleźć fragmenty sprawdzające obecność układu "zabezpieczającego" to tutaj ich nie widać... być może "piraci" je usunęli razem z napisami, a być może ich nie było wcale. Aby mieć pewność należałoby dokładnie przejrzeć cały kod, w szczególności ten który zawiera nowszą wersję KOS-a (2.0). Należy dodać iż ten KOS 2.0 może zainstalować również RAM-dysk wykorzystujący dodatkowe banki pamięci, jak i również pamięć od OS-em czy też w przypadku użycia BASIC-a pomięć RAM pod BASIC-em.
Ponieważ oryginalny dump (ten mający rozmiar 16KB) trudno w oczywisty sposób uruchomić pod emulatorem, przygotowałem dwa oddziele obrazy pozwalające uruchomić je pod emulatorem wybierając jako typ cartridge "Phoenix 8K".
I na koniec prezentacja wyglądu owego cartridge:
płytka drukowana, góra:
płytka drukowana, spód:
EDIT: zauważyłem że na schemacie jest różnica w stosunku co do oryginalnego carta, tzn. zamiast oryginalnie zastosowanego 7403 (wyjścia open collector) oznaczyłem bramki jako 7400 (push-pull)... na szczęście w tym wypadku nie ma to większego znaczenia (układ wyprowadzeń ten sam) a w powyższej konfiguracji układ będzie działał zarówno z 7400 jak i 7403. Oczywiście "zabezpieczenie sprzętowe" też będzie działać, bo dioda 1N4148 będzie symulowała wyjście open-collector nawet w przypadku zastosowania 7400. Poprawię to oczywiście w wolnej chwili.
@atarixegs: dzięki za info! niezły mod... :) z ciekawości jeszcze zapytam... pamiętasz co napisane było na scalakach? tzn. na jakich scalakach bazuje konwerter?
@fox: jasne rozumiem, zmieniłem na .zip. Prawdę mówiąc zakładałem że i tak ludzie używają PC aby ściągnąć pliki z internetu. Ale PIN jak widać używa telefonu... ja nawet nie zakładałem takiej opcji bo ja nie używam telefonu/tabletu to takich celów ;) następnym razem wrzucę Pinowi archiwum w formacie .bz2 albo .xz ... ;P
ehhh, szkoda że zipem spakowane. 7z potrzebny do spakowania 703 bajtów :) Teraz muszę odpalić piec, rozpakować to, przepakować do zipa, wrzucić na ftp i zassać telefonem przerzucając to przez sio2bt. Jak by nie to, to wystarczy telefonem zipa wprost do atarki zrzucić, gdzie zipa rozpakujesz bez łaski ;)
Uprzejmie donoszę też, że zabawnie wraca do dosa, zimny reset jest konieczny, no i rozwala Spartę.
Pin, spakowane 7z nie z powodu chęci zaoszczędzenia miejsca, ale tylko i wyłącznie z tego powodu aby mieć pewność że sciągnięty plik jest poprawny (7z zapewnia integralność danych, a przynajmniej wiesz jeżeli coś się z archiwum spierniczyło po drodze). Ale ok wrzucę Ci na pigwę wersję .XEX.
Co do sparty... wytłumacz mi proszę jakie ty masz memlo? ;) program się ładuje od $2000, jakim cudem Ci to Spartę rozwala? Mogę go skompilować wyżej... ale też trzeba uważać bo przecież zaraz będziesz narzekał że jak bedzie ponad $a000 to trzeba będzie ładować przez /X czy coś bo tam też sparta... :) powiedz gdzie ma się ładować aby nie robiło "kuku" sprawcie.
i Ty mówisz na poważnie, że takiego programu:
$22C0 - $2572 : $02B3
RUN $2473nie da się normalne załadować spod sparty? serio? ;)
Czy do tak prostej "popierduły" mam dołączyć relokator i relokować dynamicznie w zależności od memlo? czy może jednak
wystarczy ładować nieco wyżej aby Sparta mogła żyć spokojnie?
Jak mi napiszesz co mam zrobić aby zadowolić spartę, chętnie poprawie te $2b3 bajtów kodu ;P
EDIT: Pin, specjalnie dla Ciebie wersja 1.1, ładowana od $8000, i to w formie XEX: Video Latency Test v.1.1.xex
Dodatkowo po wciśnięciu ESC robi WARM START/RESET powinno wrócić do Sparty bez problemu? nie?
Tak, to ten konwerter, przy czym u mnie odwzorowuje świetnie a u kolegi tr1x wygląda to fatalnie bo nie ma modu supervideo w atarce.
Jeszcze raz dzięki za tak rozbudowane informacje na temat konwertera i jego zachowania w różnych trybach pracy. A możesz podpowiedzieć którą dokładnie wersję do super video w swoim Atari posiadasz?
dzięki za info! czyli sam "konwerter" który posiadasz wydaje się być całkiem OK? Rozumiem że dobrze on sobie radzi z interlace? (zarówno tym pseudo, nazwijmy go 240i /via software/ jak i tym sprzętowym 480i by Rybags). Bo rozumiem że mówisz o konwerterze z np. tego wątku: http://www.atari.org.pl/forum/viewtopic.php?id=15674
Seban, jestem pod wrażeniem Twojej płodności programistycznej :-) Bardzo ciekawy tool.
nie przesadzajmy z tą "płodnością"... to naprawdę nie zajęło dużo czasu i napisanie tego nie wymagało zbytniego wysiłku. Na tym forum są ludzie którzy kodują takie rzeczy że jestem przy nich totalnym cieniasem :)
Napisz jeszcze jak podłączyłeś oba monitory na raz do Atari.
W przypadku zdjęcia które zamieściłem, podłączenie było proste i oczywiste, a to tylko dlatego że komputer testowy miał na pokładzie VBXE... LG dostawał sygnał RGB z VBXE na swoje wejście EURO/SCART... natomiast CRT dostawał tylko sygnał luma (taki kabel miałem pod ręką).
A następne testy robiłem zupełnie niezgodnie ze sztuką ... powinienem był "na prędce" skleić chociaż jakiś wtórnik/bufor do sygnału wideo ale poszedłem na totalną łatwiznę... i zastanawiając się czy ryzykuję obciążyłem wyjście atari dwoma monitorami jednocześnie więc 75ohm impedancji zmieniło się w straszliwe 37ohm... ja się zastawiałem co na to powie Atari i jak długo wytrzyma :) ale radziło sobie dzielnie i efektem ubocznym był spadek amplitudy sygnału video co przełożyło się na delikatne zmniejszenie poziomu jasności...
... wiem, wiem... wypisuje herezje i postępuje krocząc ścieżką zmierzającą ku zagładzie ;P jednak nie zależało mi na jakości ani ostrości obrazu... wszystko miałem podłączone do jednej listwy zasilającej i nie miałem żadnych "ground loops" i prawdę mówiąc nie sądziłem że to zadziała dobrze, a jeżeli zadziała to spodziewałem się o wiele większej degradacji sygnału jednak zdziwiłem się tym co ujrzałem przy innych testach więc szybko przestałem się przejmować ;) naprawdę zwyciężyło lenistwo i nie chciało mi się nic lutować... więc zrobiłem kablową maskarę typu:
[monitor#1]-------\
|---------[CVBS signal]-----[Atari]
[monitor#2]-------/potem się trochę ogarnąłem, i zrobiłem dwa wtórniki na szybkim op-ampie przeznaczonym do tego celu... jednak sądzę że można to wykonać również z dwóch tranzystorów. Teraz przyszedł mi do głowy jeszcze jeden pomysł, ale nie wiem czy zadziała... sprawdzę go i dam znać niebawem :)
I nikomu nie polecam takiego postępowania jakie zaprezentowałem wyżej, ja ryzykowałem na własną odpowiedzialność... ale to nie było mądre... tak naprawdę wystarczy że jakiś TV będzie miał jakiś nietypowy układ wejściowy czy jakąś składową stałą na wejściu video i mogą zacząć się problemy. nie powinno się tak postępować jak to uczyniłem, konsekwencje mogą być różne. Jak napisałem niebawem dam znać jak podłączyć dwa monitory jednocześnie bez większego ryzyka.
Nie mam CRT ale zrobiłem sobie pokrętny test samego konwertera - sygnał S-video podany równocześnie z Atari bezpośrednio do monitora i do konwertera HDMI a z niego do monitora po DVI. Na monitorze odpalony PIP, z lewej DVI, z prawej S-video.
Konwerter spóźni się o 1 ramkę. Teoretycznie bo praktycznie nie wiem jak realizowany jest PIP
no właśnie taki rodzaj pomiaru daje wiele niewiadomych, dlaczego? postaram się pokazać to na przykładzie...
tutaj fota gdzie atari podłączono to taniego monitora LCD przez HDMI z użyciem konwertera który ma minimalne latency (właściwie kilka linii skaningowych)...
jak widać sam monitor przy przetwarzaniu sygnału z zewnątrz wnosi opóźnienie rzędu 2 klatek... ale ten model to taki low-cost all in one... tzn. ma również wejścia EURO/SCART, S-Video, Component, Composite Video. I co się stanie jak podłączymy Atari do tych wejść bezpośrednio?
wyszło na to że konwersja sygnału cvbs zajęła bebechom monitora kolejne dwie klatki, co byłoby dość logiczne, ponieważ konwerter zapewne czeka aż przyjdą do niego dwa kolejne pół-obrazy systemu PAL... po czym składa sobie jedną klatkę obrazu przy okazji robiąc masakrę z sygnału 240p który otrzymał od atari...
i dlatego pisałem wyżej że Twoja metoda pomiaru może (ale nie musi) dawać nieadekwatne testy...
ale dzięki Twojemu wspomnieniu o braku CRT... Kurdę chyba wpadłem na pewnie pomysł jak to zrobić bez CRT :D to ma szansę zadziałać, ale muszę to sprawdzić :)
Wracając na chwilę do tego nieszczęsnego mistrala jak pisałem ten monitor również (tak jak LG) robi istną kaszanę z sygnału 240p... tak będzie robić również większość TV, konwerterów, etc. (u Ciebie też chyba widać na zdjęciu że obraz z prawej strony jest nieprawidłowy i drży o jedną linię co ramkę (no chyba że czas "otwarcia migawki" za długi jest))
Muszę jednak dorobić jakiś test pokazujący/testujący nieprawidłowe przetwarzanie sygnałów 240p przez większość sprzętu obecnego na rynku.
Dlaczego wygłaszam tak pesymistyczną opinię... tylko dlatego że 240p nie jest żadnym standardem, a w stanach FCC zabroniło nadawania w tym formacie, żaden sprzęt studyjny nie wspiera tego formatu. 240p to właściwie "hack" który działał na analogowych TV/Monitorach (stąd też słynne scan-lines jako efekt uboczny).
Napisałem program podobny do tego "lag-test" z pakietu "240p test suite" i pozwoliłem go sobie zaprezentować w tym wątku: Video Latency Test. Może się przyda do dalszych pomiarów.
Zainspirowany ostatnimi postami dotyczącymi różnego rodzaju maści video-konwerterów, scalerów, a także wątkiem forumowicza tr1x (Test opóźnienia telewizora CRT, LCD i konwertera wideo).
Postanowiłem napisać taki prosty "Video Latency Test", inspirując się "lag testem" z pakietu 240p test suite.
Ten mini program nie wygląda zbyt imponująco:
Po uruchomieniu "Video Latency Test" użytkownik zobaczy liczniki zliczające, kolejne ramki telewizyjne generowane przez Atari, sekundy, minuty i godziny. Dodatkowo każda nowa ramka powoduje podświetlenie kolejnej z dużych cyfr widocznych na ekranie. Nic w tym ciekawego dla ludzkiego oka, jednak pojawiają się ciekawe możliwości jeżeli uzbroimy się w aparat fotograficzny, ew. kamerę/telefon które może kręcić filmy z prędkością 50/60 klatek na sekundę.
Aby poprawnie dokonać pomiaru opóźnienia wprowadzanego przez dany monitor, konwerter, scaler potrzebne jest źródło obrazu referencyjnego... takie o znanym opóźnieniu lub takie o zerowym opóźnieniu, takim źródłem będzie klasyczny monitor CRT który nie buforuje i nie dokonuje obróbki sygnału wejściowego tylko od razu go wyświetla.
Aby przeprowadzić poprawny pomiar należy ustawić takie monitor referencyjny obok monitora na którym będzie wyświetlany sygnał którego opóźnienie chcemy zmierzyć (może to być pomiar np. opóźnienia przetwarzania samego monitora LCD lub pomiar opóźnienia wprowadzanego przez konwerter).
Przykładowy zestaw testowy zestawiony z monitora CRT CM11342/00G oraz monitora LCD LG M228WA, wygląda tak:
Zdjęcie powyższego zestawu zostało wykonane aparatem cyfrowym z ustawionym na sztywno czasem naświetlania na 1/50 sek. (gdyby Atari pracowało w systemie NTSC, należało by ustawić czas naświetlania na 1/60 sek.)
Ze zrobionego zdjęcia wynika że monitor LCD wprowadza dwie klatki opóźnienia w stosunku do obrazu generowanego przez Atari (CRT wyświetla już ramkę nr 4, natomiast LCD próbuje wyświetlić ramkę nr 2). Nie jest to jeszcze złym wynikiem, jednak bardziej niepokojący jest czas reakcji matrycy... można zaobserwować że matryca LCD ma bardzo długi czas reakcji, tak właściwie widać że jeszcze widać poświatę na cyfrze "0", ogromną poświatę na cyfrze "1" oraz to że ramka z podświetloną cyfrą "2" nie została jeszcze w pełni wyświetlona (o ile udało się zareagować matrycy na zamianę ciemnego w jasne, to zamiana jasnego obszaru cyfry "2" w ciemny nie udała się jeszcze w pełni).
Pokazuje to tylko jak wolne czasy reakcji prezentuje matryca zastosowana w tym wiekowym modelu monitora. O innych efektach ubocznych które powstają na LG M228WA za chwilę.
Oczywiście monitor CRT reaguje pięknie i dynamicznie, obraz uchwycony na zdjęciu za każdym razem jest ostry, kineskop nadąża za dynamicznymi zmianami znakomicie. Opóźnienie jest zerowe. Jeżeli chcieć by się przyczepić to widać (ale tylko na zdjęciu) minimalną poświatę na cyfrze z poprzedniej klatki.
Ten test testuje jedynie "opóźnienie" wprowadzane przez dany monitor, konwerter, etc. Na chwilę obecną nie testuje jakości przetwarzania sygnału 240p (taki generuje domyślnie Atari) przez wszelakiego rodzaju monitory LCD, konwertery, etc. Jeżeli będzie potrzeba lub zainteresowanie tematem opracują odpowiedni zestaw testów umożliwiający przetestowanie przetwarzania różnych formatów obrazu generowanych przez Atari.
Wyprzedzając nieco wydarzenia mogę powiedzieć że żaden z tanich konwerterów/scalerów oprócz wprowadzania opóźnień rzędu od kilku do kilkunastu ramek, robi z takiego sygnału prawdziwą masakrę.
Nie sięgając daleko, nawet sam monitor LG M228WA znośnie wyświetla jedynie statyczny obraz z Atari, natomiast gdy tylko jakiś obiekt na ekranie się porusza, wbudowany w TV software próbuje "na siłę" poprawiać obraz i wydaje mu się ze wie lepiej co powinien wyświetlić zamiast oryginalnego obrazu... a zatem dodaje od siebie filtrowanie, de-interlace, wygładzanie, wyostrzanie, etc. Oprogramowanie w monitorze jest fabryczne i nie da się w żaden sposób tychże polepszaczy wyłączyć (mówię o sytuacji gdy sygnał podłączony jest do gniazda EURO/SCART, S-Video lub Composite Video w monitorze).
Kończąc już ten nieco przydługi wątek (bo jak zwykle się rozpisałem)... jeżeli kogoś to interesuje to oprogramowanie można pobrać tutaj: Video Latency Test v.1.1
Na chwilę obecną żadna instrukcja nie jest potrzebna. Program należy po prostu uruchomić z dowolnego medium/nośnika (ma postać standardowej binarki Atari DOS [XEX] więc nie powinno być żadnego problemu). Jeżeli komuś przeszkadza niebieskie tło, można go zmienić na czarne wciskając klawisz SHIFT w dowolnym momencie). Soft rozpoznaje system TV (PAL/NTSC) w którym pracuje Atari i odpowiednio dostosowuje swoje ustawienia.
Program oczywiście można uruchomić na emulatorze, ale chyba tylko po to aby pokazać jak trudno dobrze wyświetlić dynamiczny obraz generowany przez Atari w systemie nadrzędnym, często również w przypadku niezgodności prędkości odświeżania monitora oraz obrazów generowanych przez emulator).
Z czasem wrzucę również na forum Atari Area (zapewne gdzieś w dziale sprzęt) testy konwerterów które posiadam aby pokazać czego należy za wszelką cenę unikać i nie wyrzucać pieniędzy w błoto.
EDIT@2018.12.25: aktualizacja wersji do 1.1, zmiana .7z na .zip
Naiwnie sądziłem że najwięcej pracy będzie ze zrzuceniem tego, więc zrzucałem jak leci... schematy rysowałem na kartkach, etc. A teraz mi wyszło że przygotowanie tego publikacji tutaj to o wiele więcej roboty :) przerysowanie tego z kartek, przypomnienie sobie jak to było :) właściwie to na własne życzenie robię tą robotę ponownie.... tzn. końcowe szlify :) a to zaktualizuje zdjęcia, a to poprawię schemat, a to coś mi się przypomni... także proszę jeszcze o chwilę cierpliwości.. .skończę niebawem z cartami i polecą magnetofony :)
Jedna uwaga co do elektroniki... zastosowanie fotorezystora jest w tym wypadku wydaje się niewłaściwe, średni czas reakcji fotorezystora jest za wolny do tego testu... noty katalogowe podają czas reakcji na poziomie aż 30ms... radziłbym zastosować fotodiodę lub fototranzystor, wtedy nie będziesz miał dodatkowego opóźnienia wnoszonego przez czas reakcji fotorezystora.
EDIT: jeszcze jedno jeżeli chodzi o pomiar czasu opóźnienia scalerów/graberów/scan-converterów względem CRT to stosuje się zazwyczaj metodologię polegającą na wyświetlaniu tego samego dynamicznego obrazu na dwóch monitorach równocześnie, tzn. CRT robi jako źródło referencyjne, LCD + konweter, up-scaler, etc. jest traktowany jako obiekt mierzony. Uruchamiasz soft testowy, np:
240p test suite <--- a dokładniej chodzi o lag-test z tego pakietu.
i robisz zdjęcie/kręcisz film obu monitorów jednocześnie,test wygląda np. tak: http://youtu.be/jQ_z6DYx2wU
Myślę że nie jest jakimś dużym wyzwaniem napisanie takiego testu natywnie dla 8-bit Atari.
Kolejny cart "na tapecie" i jest to kolejny Blizzard, tym razem jednak EPROM zawiera zestaw oprogramowania zajmujący 8KB, w środku:
Turbo KOS by KNS
Micro Loader 2.2
Blizzard Copy 55KB (v.3.7)
Tape Test
1) Zawartość pamięci EPROM: Blizzard 8K Cartridge
blizzard_8k.bin:
MD5 : 6fca83b30203576021a1a3d6680195f5
SHA256: 536b237aa8bba96e20af821812985d22cc139a764f53339592547dacdc6d1a362) wersja XEX dająca się uruchomić spod DOS-a lub dowolnego loadera plików binarnych: Blizzard_8K.xex.
Jest to standardowa konstrukcja tego typu carta, mapowany jest w obszarze $A000-$BFFF, z możliwością programowego odłączenia przez dowolne odwołanie (odczyt/zapis) do dowolnej komórki z przedziału $D500-$D5FF. Obraz cartridge można uruchomić pod emulatorem wybierając "Phoenix 8K".
Układ odłączenia zrealizowano na prostym przerzutniku RS, zbudowanym z bramek NAND. Dowolne odwołanie do $D5xx powoduje aktywność sygnały ~CCTL, a co za tym idzie wyzerowanie przerzutnika i ustawienie sygnału RD5 w stan 0, co przez system i sprzęt jest postrzegane jako odłączenie cartridge. Ponowne włączenie może nastąpić gdy użytkownik wciśnie przycisk RESET umieszczony w cartridge, lub po ponownym włączeniu zasilania (przerzutnik po włączeniu jest ustawiany przez układ reset zbudowany z R1/C2, co powoduje iż RD5 ustawia się na "1", przez co cart zauważany jest przez MMU i pojawia się w przestrzeni adresowej $A000-$BFFF).
3) Schemat: wektor (PDF), raster color (PNG), raster grayscale (PNG).
Sam cartridge prezentuje się tak, i trudno orzec czy jest to jakieś "giełdowo/pirackie" wydanie, czy też po tylu latach brak "oryginalnej" naklejki... być może ktoś sam wykonał sobie "klon", jednak ścieranie napisów na scalakach sugerowałoby raczej działalność giełdowego handlarza:
PCB góra:
PCB spód:
Dzięki za weryfikację i poprawny schemat! Jednak moje zgadywanie poszło nie w tym kierunku, poprawię także swój schemat. Twoja wersja wygląda o wiele sensownej... Na szczęście moje pomyłki nie zmieniają mechanizmu bankowania, tylko namieszałem w układzie zerowania przerzutników... i to mnie dziwiło że autor carta coś namieszał ;) a to się okazało że nie autor, tylko ja już ślepy jestem :)
kawał porządnej roboty! :) wygląda świetnie!
Hej!
No świetne wieści! Cartridge udało Ci się naprawić! :) Tak właśnie powinien działać! Teraz możesz być pewien że oprogramowanie i sam cartridge działa bezbłędnie :) Fajnie że udało Ci się doprowadzić to do działania! :)
Z tego co piszesz teraz pozostaje Ci powalczyć trochę z magnetofonem... bo widać że coś jeszcze jest na rzeczy... w carcie KNS BIG, gdy uruchomisz Super Cartridge 4.0 to jest tam program "head set", zobacz jak wygląda sygnał nagrany na kasetę przy użyciu tego programu. ew. użyj "Tape Doctor I", on wizualizuje to trochę lepiej, będziesz wiedział czy sygnał sygnał "wygląda dobrze".
Skoro głowica jest ustawiona OK, to tak jak piszesz, warto poeksperymentować z poziomem sygnału, ma on spore znaczenie. Nie wiem jakich źródeł do nagrań używasz, ale aby mieć pewność że wszystko OK, możesz zawsze wygenerować sobie "świeże" przy pomocy "Turgen System" <--- Dzięki mozolnej pracy baktraaa, wspiera on na szczęście również format Blizzard Turbo :)
EDIT: ... przypomniało mi się... zajrzyj do tego wątku ... Turbo Blizzard - porady Zenona/Dial
Dzięki uprzejmości kolegi robecc, który dokonał "zrzutu" pamięci EPROM zawartej w cartridge ze swojej kolekcji, mogliśmy się cieszyć z kolejnego ocalonego z przeszłości produktu jakim był cartridge nazwany "Universal Turbo". Jak się okazało po szybkiej analizie było to połączenie software dla systemu Blizzard oraz dodatkowo zestaw oprogramowania dla czechosłowackich systemów Turbo 2000, Turbo UNI*, Turbo ZXL 3.1.
robecc zgłaszał że nie udaje mu się uruchomić poprawnie całości carta pod emulatorem, więc postanowiłem dokonać analizy powstałego problemu. wstępne wyniki pokazały że ten cart ma swój odmienny sposób przełączania banków, po szybkim sprawdzeniu zawartości udostępnionego pliku i upewnieniu się że wszystko z nim jest OK, postanowiłem zająć się tym dokładniej w wolnej chwili, zaczęło się spokojnie, ale im bardziej wnikałem w kod tym ciekawiej się robiło... koniec końców spędziłem nad tym trochę czasu i postanowiłem się podzielić tym co z tego wyszło, zacznijmy zatem tą nieco przydługa opowieść... ;-)
Cartridge po włączeniu, startuje w trybie Blizzard:
Czyli wygląda to jak standardowy cartridge dla systemu Blizzard, w którym dostępny jest:
Turbo K.O.S.
Microloader 3.2
Blizzard Copy
Z oprogramowania dla Blizzard usunięto jednak wszystkie informacje o firmie KNS która widnieje w innych oficjalnych wersjach cartridge dla Blizzarda. Wszędzie gdzie znajdowały się informacje o autorstwie KNS widnieją tylko puste miejsca/spacje.
Dodatkową opcją widniejącą w menu głównym dla Blizzard-a jest możliwość przejścia do "CS Turbo System" przy pomocy klawisza ESC. Zapewne litery "CS" oznaczają "Czechoslovak" , ale o tym później, po wciśnięciu ESC uruchamia się niejako drugie oprogramowanie "zaszyte" w pamięci cartridge:
.
Jak już pisałem robecc wspominał że nie udaje mu się w pełni uruchomić obrazu cartridge pod emulatorem, a ponieważ mi też się to nie udało, postanowiłem spróbować narysować schemat na podstawie zdjęć które udostępnił kolega robecc. Zdjęcia musiałem trochę przekształcić/wyprostować abym mógł złożyć warstwy, aby nie musieć tyle zgadywać i zmniejszyć prawdopodobieństwo popełnienia kardynalnych błędów. Co prawda nie widziałem układu ścieżek pod układami scalonymi, ale ekstrapolując nieco i zaglądając w kod umieszczony w cartridge udało się odtworzyć układ połączeń, zatem:
Schemat: wektor (PDF), raster color (PNG), raster grayscale (PNG).
Wartości elementów R,C mogą być niepoprawne, ponieważ nie widać napisów na nich, ale założyłem na podstawie poprzednich cartów, że wartość kondensatora na linii ~CCTL to pewnie ~560pF. Widoczne na zdjęciu rezystory nie mają pasków, a napisy świadczące o ich wartości są niewidoczne. Założyłem więc bezpieczną wartość ~10kOhm, zapewne jednak może to być coś w zakresie 2.2-4.7kOhm zapewne. Jeżeli robecc zechce to zweryfikować to poprawię oznaczenia na schemacie. Robecc dokonał weryfikacji wartości elementów, narysował także poprawny schemat, ponieważ popełniłem błędy przerysowując swoją wersję ze zdjęć.
Po narysowaniu schematu można było już "zobaczyć" zasadę bankowania carta i sposobu sterowania jego bebechami, wtedy też stało się jasne że żaden znany mi emulator nie wspiera takiego typu carta. Szanowny kolega Krótki, obecny na tym forum już kiedyś dopisał emulację cartridge AST-MULTI Cartridge,do Atari800, więc licząc że może znajdzie kiedyś czas na dopisanie emulacji kolejnego carta, postanowiłem że opiszę tutaj sposób działania tegoż egzemplarza, tak więc:
Cart ma na pokładzie 16kB pamięć EPROM, pamięć zajmuje obszar $A000-$BFFF i jest podzielona na dwa banki po 8KB. Cartridge można wyłączyć i włączyć programowo, również programowo można dokonać wyboru banku (1 z 2) widocznego w przestrzeni adresowej $A000-$BFFF.
Pominę w opisie już uwagi dotyczące, dość frywolnego podejścia konstruktora tego carta, przez co ma on "niepewną", a tak właściwie to przez duży łut szczecią działającą elektronikę (chociażby przez brak poprawnego układu resetującego przerzutniki). Okazało się że nie było to "frywolne podejście konstruktora" a jedynie błędy które popełniłem "odzyskując" schemat ze zdjęć, no cóż... na przyszłość pozostaje mi zachowanie większej uwagi, mniej nadinterpretacji i bardziej ostrożna ekstrapolacja z brakujących danych :D
Koniec końców ma to działać mniej więcej tak:
Zaraz po włączeniu zasilania przerzutniku ustawiane są tak że na wyjściu ~Q przerzutnika U3B pojawia się "1" logiczna, a więc linia A13 dla EPROM zostaje ustawiona na "1". W przestrzeni adresowej $A000-$BFFF pojawia się zatem obszar $2000-$3FFF z pamięci EPROM. Równolegle na wyjściu Q przerzutnika U3A ustawiane jest "0" logiczne, które potem zostaje zanegowane przez inwerter stworzony z bramki U2B, co w efekcie daje "1" na jej wyjściu które to ustala stan linii RD5 na owe "1", które to powoduje że cartridge zostaje włączony przez MMU i pojawia się w przestrzeni adresowej $A000-$BFFF.
Oba przerzutniki są taktowane w ten sposób iż zapamiętują stan linii adresowych (odpowiednio A6 i A7) w momencie jakiegokolwiek dostępu (odczyt lub zapis) w obszarze $D500-$D5FF. Jakie to niesie za sobą konsekwencje?
Dostęp do dowolnej komórki z przedziału $D580-$D5FF spowoduje wyłączenie cartridge (gdy A7=1, wyjście Q przerzutnika U3A = 1, po inwersji bramką U2B stan RD5 = 0.
Dostęp do dowolnej komórki z przedziału $D540-$D57F, spowoduje włączenie banku 0 w cartridge (gdy A6=1, wyjście ~Q przerzutnika U3B = 0, więc linia A13 pamięci EPROM=0, co za tym idzie w przestrzeni $A000-$BFFF Atari widać obszar $0000-$1FFF pamięci EPROM).
Dostęp do dowolnej komórki z przedziału $D500-$D53F, spowoduje włączenie banku 1 w cartridge (gdy A6=0, wyjście ~Q przerzutnika U3B = 1, więc linia A13 pamięci EPROM=1, co za tym idzie w przestrzeni $A000-$BFFF Atari widać obszar $2000-$3FFF pamięci EPROM).
Jak już wspominałem ten mechanizm "bankowania" cartridge na chwilę obecną, według mojej obecnej wiedzy nie jest wspierany przez żaden z emulatorów. Zaczęło mnie nurtować, czy nie dało by się zrobić wersji .XEX ładowanej bezpośrednio do pamięci komputera, jednak w tym wypadku nie było to tak trywialne, jak w przypadku większości cartridge. O ile część obsługująca "Blizzard" jest prostym 8kB cartridge i korzysta jedynie z możliwości wyłączenia się z poziomu własnego kodu, to "CS Turbo" dokonuje wielokrotnego włączenia i wyłączenia samego siebie... a to w celu kopiowania danych w różne obszary, w tym w obszar pamięci znajdujący się "pod" obszarem cartridge, a to w celu "pozbierania" się po reset, a to w celu relokacji loadera w inny obszar pamięci. Zacząłem więc przeglądanie tego kodu, aby zastanowić się czy da się to jakoś ogarnąć i zrealizować wersję .XEX ... trochę to trwało, ale okazało się że jest pewna szansa... a piszę o tym wszystkim tylko dlatego że podczas analizy kodu części "CS Turbo" ze zdziwieniem stwierdziłem, że w menu startowym było początkowo więcej pozycji niż obecnie widoczne na ekranie 6!
W oryginalnym carcie było tych pozycji 8. Zmiana wykonana przez "zblizardownie" carta polegała na okrojeniu "CS Turbo" do 8KB, a autor tej modyfikacji wywalił z menu pozycję 7-8, które jak mu się wydawało zajmowały drugie 8KB pamięci EPROM, usunął zatem z menu pozycje 7-8, ale zrobił to "po najmniejszej linii oporu", tzn. skasował tekst jedynie tekst z menu, trochę zmodyfikował Display List (usunął 1 linię). Nie mienił natomiast sprawdzania zakresu wybieranych klawiszy, przez co klawisze 7-8 pozostały aktywne, i teraz robi się naprawdę ciekawie ... bo np. wciśnięcie klawisza "8" w menu powoduje co prawda przepisanie bzdur do pamięci i przysłowiowy skok w maliny (końcowym efektem jest zawieszenie się komputera), ale wciśnięcie klawisza 7 w menu "CS Turbo" powoduje że ukazuje się:
... okazuje się że pozycja nr. 7 z menu umiejscowiona jest pod koniec 8KB obszaru okupowanego przez CS Turbo, wygląda na to że jest cała. Nie wiem zatem czemu autor tego carta postanowił ją wymazać z menu (być może chodziło o to że widać autora Turbo TOS-a?). Tak czy inaczej, pozycja nr 7 inaczej jest obecna w EPROM i postanowiłem, ze robiąc wersję XEX dodam nieco poprawek i modyfikacji, łącznie z przywróceniem tej pozycji w menu. A wygląda to po poprawkach tak:
Pozostało mi nieco opisać poszczególne pozycje dostępne w menu:
1,2) Turbo 2000 / Turbo 2000N:
Jest to niewielki i kompaktowy loader lokujący się w obszarze $05BA-$06FF, lub $B5BA-$B6FF w przypadku wersji "N".
3,4) Universal TURBO* / ZXL 3.1:
To dwa kolejne loadery, nieco dłuższe i prawdopodobnie obsługują inny format zapisu danych. Loader Uni* lokuje się pamięci w obszarze $458-$6FF, natomiast ZXL 3.1 w obszarze $400-$6FF. Ponieważ nie analizowałem kodu tych loaderów nie wiem jaki format danych obsługują. Nie spotkałem równie nigdy wcześniej żadnych programów zapisanych w tym systemie/formacie.
5) Turbo Copy:
Zapewne program kopiujący programy w standardzie Turbo 2000, okupuje przestrzeń adresową $0458-$0A64
6) Turbo DOS P:
Handler Turbo dla BASIC-a, instalujący urządzenie "T:", ma również swoje mini-menu dostępne po wydaniu polecenie DOS z poziomu BASIC-a, ale najciekawsze jest to że zawiera w sobie również sterownik dla drukarki obecny jako urządzenie "P:", nie zgłębiałem kodu, ale wychodzi na to że próbuje komunikować się z drukarką używając portów joysticka jak interface komunikacyjnego. Analizę tego fragmentu kodu pozostawiam już zainteresowanym osobom. Obszar zajmowany przez tą pozycje to $0AF0-$1055.
7) Turbo2000 Operating System V4.1:
Wspominany już wcześniej "Turbo 2000 Operating System V4.1". Nieobecny w oryginalnym menu, a przywrócony po nierównej walce ;) Po uruchomieniu zajmuje on obszar $0B00-$1772, zgłaszając MEMLO na poziomie: $17D4.
Wcześniej wspominałem że "CS Turbo" może oznaczać "Czechoslovak Turbo", właśnie z powodu tej pozycji w menu... autorem Turbo 2000 OS jest Milan Riha, co sugeruje pochodzenie systemu właśnie z Czechosłowacji, również format danych Turbo2000 jest podobny co Czechosłowackich rozwiązań z tamtych czasów.
Ciekawe czy te czechosłowackie systemy miały jakikolwiek wpływ na nasze polskie konstrukcje typu KSO 2000 czy Turbo 2T06... już kiedyś snułem dywagacje na ten temat... i sądzę że systemy z Czechosłowacji były jakąś inspiracją dla polskich konstruktorów. A w niektórych przypadkach można nazwać niektóre konstrukcje i pomysły plagiatem.
I kończąc już, dla porządku (aby wszystko było już w jednym miejscu/poście:
8) Poprawiona wersja XEX do pobrania tutaj: Universal Turbo Cartrige - patched
9) Oryginalny dump pamięci EPROM wykonany i udostępniony przez robecc: Universal Turbo EPROM
universal_turbo.bin:
MD5 : d9b152a5829b09ead1f75cbf8bd81eac
SHA256: 0f3150194aaf13985f75791d781a65d1dcf8a28c75d3b58ab67a1fa73b3d4bab10) Poprawiony dump pamięci EPROM (poprawione menu, i pomniejsze poprawki w kodzie): Universal Turbo EPROM (patched)
universal_turbo_patched.bin
MD5 : cd62fd3f6b88de8788ef738eef838377
SHA256:f726e5af44458116830d3bbbbb082747832f7163d912da63d13ebd299365e613zdjęcia wykonane przez robecc, tutaj trochę przetworzone i wyrównane:
PCB góra:
PCB dól:
sam cartridge:
To jak będziesz już w sklepie to może kup na wszelaki wypadek jeszcze jakieś "74LS00", będzie kosztował grosze a może się okazać że wiekowe UCY7400 jakoś już nie domaga ;)
atari.area forum » Posty przez seban
[ Wygenerowano w 0.638 sekund, wykonano 10 zapytań ]