To nie jest takie proste. Autor jest nieuchwytny. Ostatnia próba nawiązania kontaktu i transakcji miała miejsce w 2019 roku, ale bez powodzenia.

Nie starannie dobierałam słowa. Możemy kontynuować dyskusję tutaj w tym wątku, a ja odpowiem na wszystko, co dotyczy czechosłowackich systemów turbo (lub więcej), jeśli ktoś jest zainteresowany. I jeśli wiem.

Informacje, które posiadam, pochodzą ze skanów starych magazynów i dokumentacji, magazynu FLOP oraz kontaktów ze starszymi entuzjastami Atari. Dużo informacji zdobyłem przy tworzeniu TURGENa.

Nie jestem jednak naocznym świadkiem tych ciekawych czasów w Czechosłowacji. W latach 1987-1993 byłem zbyt młody, aby angażować się w jakąkolwiek grupę użytkowników.

Będę też wdzięczny, jeśli na Atariki pojawią się informacje o czechosłowackich systemach turbo. Z Google mogę się komunikować. Pisanie artykułów wiki nie wystarczy

Miało być wszystko powoli i na spokojnie, jednak wytrącony z rytmu pracy przez różne rzeczy postanowiłem o tym napisać już teraz, ostatnio przeglądałem sobie kod loaderów AutoTurbo i Wrocławskiego Turbo 2000... zacząłem zauważać dziwne rzeczy... do kompletu doszły informacje które tutaj udostępnił nam baktraaa, a jeszcze w międzyczasie dodatkowo Krzysztof "KAZ" Ziębik z AtariOnline wysłał do mnie e-mial pytając o różne rzeczy, między innymi o moje przemyślenia na temat "Wrocławskiego Turbo 2000" i braku opisu tegoż systemu w Atariki.

Przyznam że od jakiegoś czasu zbierałem się aby ten art napisać, ale rzeczy które obserwowałem w kodzie i eksperymenty które przeprowadziłem nie dawały mi spokoju... chciałem na spokojnie przeanalizować to wszystko, ale widać los chciał aby to było na wariata i po łebkach. Postanowiłem że opiszę ten system już teraz, mimo iż miałem co do niego spore wątpliwości, nie chciałem być zbyt surowy w ocenie jednak doszedłem o ściany i po prostu postanowiłem napisać to czego jestem w 90% pewien, nie wiem czy nikt się nie obrazi, ale powstał wstępny wpis o Wrocławskim Turbo 2000... jeżeli kogoś mój sposób formułowania myśli obraża i uważa że to nie tak, to proszę poprawcie mnie.

Ja tymczasem zaprezentuję wam nieco przydługi i nudy film zrobiony przy pomocy emulatora, paru obrazów cartów udostępnionych przez Voy-a (do wrocławskiego Turbo 2000), parze loaderów do czechosłowackiego systemu Turbo 2000 oraz niezawodnego Turgen-a który stworzył baktraaa, zanim jednak pokażę film to linki do wpisu na Atariki:

Turbo 2000 (Wrocławskie)

Po analizie kodu loaderów, testach i eksperymentach, zarówno na realnym sprzęcie jak na emulatorze jestem w 99% pewien że Auto-Turbo i Wrocławskie Turbo 2000 to klony systemu czechosłowackiego opracowanego przez J.Richtera w 1987 roku.

Podobieństwo nie występuje tylko w warstwie sprzętowej. Format danych używany przez Auto-Turbo i Wrocławskie Turbo 2000 jest identyczny z czechosłowackim Turbo 2000 (pisząc format danych mam na myśli nie tylko strukturę pliku ale również długość impulsów, kolejność bitów, sposób generowania sumy kontrolnej, do tego duże fragmenty kodu się pokrywają).

Loadery dla auto-turbo (które są tak naprawdę przeróbkami loaderów J.R. ) oraz oprogramowanie dla Wrocławskiego Turbo 2000 bez problemu czyta format danych czechosłowackiego turbo 2000, dla unaocznienia tego film pokazujący jak pliki wygenerowane w formacie Czechosłowackiego Turbo 2000 za pomocą Turgen-a bez problemu są odczytywane przez oprogramowanie obsługujące Auto-Turbo i wrocławskie Turbo 2000: (film jest bez dźwięku bo o nim zapomniałem, zresztą nie było by za bardzo czego słuchać). Miałem to pokazać na realnym sprzęcie, ale zdałem sobie sprawę że zanim do tego usiądę i zrobię to minie szmat czasu, zatem użyłem prowizorki i zrobiłem to za pomocą emulatora, obrazu parów cartów udostępnionych przez Voy-a, oraz mirror strony "w1k" do której linkował baktraaa (tam znajdują się loadery do czechosłowackiego turbo 2000 datowane na 1987, 1988 rok)

https://www.youtube.com/watch?v=sXsw3mmZB2o

Czyli kolejny system Turbo okazał się klonem już wcześniej istniejącego rozwiązania, które przywędrowało do Polski zza granicy.

Myślę, że jeśli wiesz kto toto spreparował, powinieneś to napisać. Przede wszystkim żeby było wiadomo od kogo jie kupować. Po drugie, jeśli to ktoś stąd to może by się wypowiedział.

Przede wszystkim oczywiście wielkie dzięki sebanie za ożywienie carta.

Znalazłem ślad po zakupie tego carta z 2012: https://archiwum.allegro.pl/oferta/-now … 56391.html
Wtedy był sprzedany jako nowy.

Po kliknięciu w "aktualne przedmioty sprzedającego" wyświetli się nazwa sprzedawcy.

Od tego samego sprzedawcy, widzę jeszcze zakup Bllizzard HIT z 2011: https://archiwum.allegro.pl/oferta/-now … 57965.html , który chyba u Ciebie już był. Możliwe że to ten:
http://www.atari.org.pl/forum/viewtopic … 17#p246617

Tak, opisałeś te poprawki: http://www.atari.org.pl/forum/viewtopic … 17#p246617

Hej!

Pora skończyć z tą "cartridge-ową dramą" i przejść nad tym wszystkim do dalszych spraw. Tym razem na warsztacie kolejny magnetofon z Blizzardem... już słyszę te głosy...  "Ale dlaczego? Jak? Po co? Znowu Blizzard? bleah!"... jednak ten blizzard to kolejne wcielenie tegoż interface... tzn. kolejne rozwiązania układowe, tym razem oparte o UL1321 i takie rozwiązanie było już zaprezentowane kiedyś przez Zenona/Dial, a schemat tej wersji opublikowanej przez Zenona można obejrzeć na Atariki: Blizzard UL1321.

Zapytacie zatem dlaczego zawracam wam głowę tożsamym rozwiązaniem? Robię to, ponieważ ta wersja którą zastałem w magnetofonie z kolekcji uicr0Bee była wersją mocno zoptymalizowaną i zawiera naprawdę bardzo niewielką, wręcz minimalna ilość elementów, do kompletu płytka jest dość mała i zgrabna. Zatem przejdźmy do prezentacji rozwiązania:

Na początku umiejscowienie płytki turbo w magnetofonie:

Góra płytki w zbliżeniu:

Spód płytki:

Jak widać płytka dość prosta, nie trzeba było stosować zaawansowanych technik zakrzywiania czasoprzestrzeni aby udało się odtworzyć schemat:

^^^ Po otwarciu obrazka w nowej zakładce będzie on zaprezentowany w wyższej rozdzielczości. Jak zwykle do pobrania również wersja wektorowa (PDF): Blizzard Turbo Interface - UL1321 version

Może teraz parę moich słów komentarza do schematu. W tej wersji zastosowani wzmacniacz małej częstotliwości UL1321 produkcji CEMI (w interface zastosowano układ z oznaczeniem L321, co oznaczało w tamtych czasach że jest to de-facto odpad produkcyjny nie spełniający wszystkich norm). A tak naprawdę dwa takie wzmacniacze w jednym układzie. Układ również posiada dodatkowy tranzystor NPN. W przypadku użycia tego układu w interface blizzard, wykorzystywany jest tylko jeden ze wzmacniaczy, reszta nie jest podłączona. W tej  konkretnej wersji interface znalezionej w magnetofonie układ UL1321 zamontowano pionowo (prawdopodobnie po to aby zmniejszyć rozmiary płytki), a nieużywane nogi układu po prostu odcięto.

Jako układ multipleksera zastosowano klasyczny 7400 (również produkcji CEMI), jednak rodzi to pewną implikację. Jak wiadomo standard SIO wymaga aby urządzenia peryferyjne podłączane do magistrali SIO miały wyjścia danych typu "otwarty kolektor". Ten wymóg jest konieczny ponieważ w wypadku konfliktu sygnałów na magistrali (np. jedno z urządzeń wystawia stan przeciwny do tego jaki panuje na magistrali) może dojść do uszkodzenia jednego z wyjść któregoś z urządzeń dołączonych do magistrali. W najlepszym przypadku nastąpi po prostu przekłamanie przesyłanych danych. Autor tego interface zignorował ten fakt i zastosował układ 7400, którego bramki mają wyjścia typu push-pull, co powoduje że wyjście tego interface staje się również wyjściem push-pull. Widać założenie było takie że ten magnetofon będzie pracował jako jedyne urządzenia podłączone do portu SIO.

Właśnie z tego względu na schemacie postanowiłem wprowadzić poprawkę, dodając diodę D1, której zastosowanie że powstaje jakaś namiastka wyjścia typu "otwarty kolektor". W Atari na linii DATA-IN znajduje się rezystor podciągający tę linię do +5V (tzw. pull-up), a zastosowanie szybkiej diody impulsowej typu 1N4148 powoduje że urządzenie może tylko i wyłącznie wymusić stan "0" na tej linii, przez co nie będzie możliwości aby nasz interface wystawiając "1" spowodowało problemy z innymi urządzeniami na magistrali. Diodę umieściłem po prostu we wtyczce SIO.

Jak widać ta wersja układu została znacznie uproszczona pod względem wersji opartej również na UL1321 zaprezentowanej przez Zenona. Autor tej wersji dokonał kilku "sprytnych" poprawek które pozwoliły na pozbycie się sporej ilości elementów (dwóch tranzystorów, czterech rezystorów).

Co jeszcze można dodać? Może to że zawsze żyłem w przeświadczeniu że UL1321 to nasze polskie rozwiązanie. Niestety jak się okazało po latach ten układ był klonem japońskiego układu LA3101 firmy SANYO. Nie mam wiedzy na temat tego czy CEMI miało licencję na produkcję tego typu układów czy je po prostu sklonowano. Faktem niezaprzeczalnym jest jednak to że te układy dało się kupić w tamtych latach w Polsce i mieliśmy możliwość produkcji własnych układów scalonych, elementów dyskretnych, etc.

Jeżeli chodzi o sam interface to działa on bardzo sprawnie i radził sobie doskonale nawet z mocno sfatygowanymi taśmami. Lokalizacja interface w magnetofonie spotykana już wcześniej (chociaż kiedyś mnie to dziwiło), ale być może tak było wygodniej i łatwiej dla montującego interface w magnetofonie.

Do magnetofonu był dołączony cartridge z oprogramowaniem. Cart "piracki", ale rozbudowany bo zawierał aż 3 niezależne carty zawierające oprogramowanie dla Turbo Blizzard, ale o tym w następnych postach za jakiś czas. Bo co prawda cart już rozrysowany i "zdumpowany", ale potrzebuję chwilę czasu aby przerysować schematy z kartek do KiCAD-a.

To chyba już wszystko co mam do powiedzenia na ten temat tego interface. Do usłyszenia wkrótce.

Hej!

Jeżeli chodzi o książkę, to pomysł powoli dojrzewa do realizacji, ale to będzie długa droga... ja jeszcze nie "obrobiłem" sprzętu który mam w kolejce, a przede mną deasemblacja całej masy kodu i analiza wszystkich procedur ładujących, także do książki czy rozbudowanej dokumentacji każdego systemu to jeszcze długa droga. Ale może kiedyś się uda, chociaż patrząc na to co się dzieje w okół przyszłość nie napawa mnie optymizmem. No i właśnie dlatego, że przyszłość nie rysuje w jakichś optymistycznych barwach postanowiłem publikować wszystko jak najszybciej, aby to co się uda mi odzyskać i udokumentować jak najszybciej znalazło się w sieci. Wiem że to wszystko jest nieco chaotyczne i mało poukładane i czasami pojawiają się nieścisłości i błędy, ale lepiej tak niż wcale, nie będę tego, kitrał gdzieś u siebie na dysku aby zgniło w zapomnieniu.

Cieszę się bardzo gdy inni ludzie również dzielą się tym co mają w swoich zasobach, to może być ostatnia chwila aby tą część historii zachować. Jak pisałem już wcześniej zbliżamy się do punktu w którym zawartość EPROM-ów (a właściwie wielkość ładunku zawartego w ich celach) zbliża się do punktu krytycznego i niebawem nie będzie już czego dumpować, bo zawartość tych kostek stanie się przekłamana lub nieczytelna.

Zatem dzięki wielkie za załączenie kolejnych plików! Cieszę się że wygrzebujesz z przeszłości i swoich archiwów takie smaczki. Ja ze swojej strony tylko dodam że te programy kopiujące wymagają do poprawnej pracy obecności handler-a "T:" dla BASIC-a, może być np. ten "Unerring Master Super Cartridge", który już udało się kiedyś odtworzyć, zdumpować i opisać w tym wątku: Unerring Master Super Cartridge.

Hej!

Jeżeli chodzi o konwersję do CAS to proszę bardzo: loader_um w formacie cas i hex.  Z tym że konwersja takiego piliku do formatu CAS powoduje że będziesz mógł jedynie używać go z emulatorem który wspiera pliki CAS zawierające segmenty typu "pwm", np. ten który zrobił FUJI: Modified atari800 emulator.

Altirra nie potrafi czytać plików CAS z tego typu segmentami, natomiast dla wersji emu od FUJI-ego nie stanowi to żadnego problemu. Sprawdziłem oczywiście i działa to bezbłędnie.

Może komuś się przyda garść informacji jak dokonałem konwersji. Być może jest inny prostszy sposób, ale przyznaję że nie czytałem zbyt dokładnie dokumentacji do pakietu a8cas-util od FUJI-ego i działałem trochę na ślepo. Jeżeli ktoś poprawi moje ew. błędy lub pokaże jak to zrobić szybciej/efektywniej/lepiej będę wdzięczny.

Czego używałem? Pakietu a8cas-util.pl od FUJI-ego uruchomionego pod  Debian 11.

Pierwszym krokiem było podzielenie pliku który podrzucił Piguła na dwa pliki/bloki. Jeden zawierał część nagrania w "normal" (fsk), drugi zawierał blok zapisany z formacie turbo. Dla zainteresowanych pliki do pobrania tutaj.

Potem mając już dwa oddzielne pliki:

• loader_um_blk01.wav

• loader_um_blk02.wav

użyłem a8cas-util w następujący sposób:

plik zawierający dane w standard:

./a8cas-util.pl conv --highpass um_blk01.wav blk01.hex
Starting ecasound... started.
SUMMARY: Data blocks: 2, std: 2 (0 E), analysed 1038336 samples.
5 HEX blocks stored in file blk01.hex.

plik zawierający segment danych w um-turbo:

./a8cas-util.pl conv --highpass -t um um_blk02.wav blk02.hex
Starting ecasound... started.
SUMMARY: Data blocks: 1 (0 Errors).
5 HEX blocks stored in file blk02.hex.

mając już dwa plik hex, po prostu połączyłem je w jeden plik:

 cat blk01.hex blk02.hex > um_loader.hex

po czym wyedytowałem plik .hex aby pozbyć się nagłówka z drugiego pliku (A8CAS-HEX, FUJI) a następnie dokonałem konwersji do CAS:

./a8cas-util.pl conv um_loader.hex um_loader.cas

Wynik operacji sprawdziłem ładując ów wynikowy plik .CAS pod emulatorem i wszytko zadziałało bezbłędnie.

Być może coś przekombinowałem i da się to jak mniemam uczynić szybciej/prościej, ale to już bardziej doświadczeni w tej kwestii muszą się wypowiedzieć raczej.

Hej!

48KHz? Twoje źródło z tego co patrzyłem jest w 44.1KHz i wydaje mi się że takie są też podzielone pliki. Jedyne co zrobiłem to wyciąłem trochę ciszy z początku bloku w standardzie, żadnej innej obróbki nie przeprowadzałem. Tylko Cut, Copy & Paste ;-)

Przyszła pora na Telesfora...

...a tak naprawdę na obiecaną kontynuację tematu magnetofonu z Blizzardem o którym pisałem wyżej, a dokładnej chodzi o cartridge dołączony do tegoż magnetofonu:

Z zewnątrz cart nie prezentuje się jakoś odmiennie od reszty kartów prezentowanych w tym wątku. Na tylnej krawędzi posiada dwa przełączniki umożliwiające wybór typu cartridge (jeden przełącza tryb pracy pomiędzy 16KB a 8KB), z drugi z przełączników umożliwia wybór jednego z dwóch  8-kilobajtowych banków. A także przycisk RESET umożliwiających ponowne uruchomienie cartridge bez potrzeby wyłączania komputera.

Cart ów zawiera kompilację oprogramowania dla systemu blizzard, dokładnie 3 cartów istniejących już wcześniej na rynku, a na jego zawartość składają się:

1) cartridge Phoenix 1.0 opracowany przez Hurka:

2) cartridge zawierający zestaw programów nazwany "Turbo Blizzrard":

3) cartridge zawierający zestaw programów nazwany "Blizzrard Cartridge":

Jak widać na powyższych screen-ach jest to "piracka" kompilacja, z podmienionymi napisami. Niejaki "SHOGUN", gdzie mógł i potrafił podmienił informacje o autorach/pochodzeniu oryginalnego softu, zastępując je swoim pseudonimem. Zmiany te zostały poczynione również w loaderach, KOS-ie czy poszczególnych programach.

Zajrzymy zatem do środka owego "stwora":

Płytka drukowana, widok od góry:

Płytka drukowana, widok od dołu:

Niestety zapomniałem zrobić zdjęć w oryginalnej postaci carta którą zastałem, a o tym fakcie przypomniałem sobie, gdy już zacząłem poprawiać płytkę carta (biały kynar i kawałek taśmy kaptonowej to już moja ingerencja w płytkę), zatem widzicie stan po kliku poprawkach. Po otwarciu wszystkie dodatkowe połączenia były wykonane za pomocą nieizolowanej "srebrzanki", i aż dziw bierze że nie było żadnych zwarć, bo w przypadku niektórych połączeń srebrzanka mijała inne punkty lutownicze dosłownie o ułamki milimetra. Postanowiłem zamienić wszystkie połączenia na bardziej bezpieczne. Cartridge oparty na tej płytce drukowanej gościł już w tym wątku, również był sygnowany podpisem "SHOGUN", można się temu przyjrzeć wracając do tego posta, w tym wątku: Blizzard 8K cartridge (pirated by Shogun)

Tym razem ponieważ cart jest bardziej rozbudowany (zawiera EPROM o wielkości 32kB i możliwa jest zmiana konfiguracji typu cartridge), obsadzono na PCB dwa układy scalone, i dokonano całej masy przeróbek aby dostosować jak mniemam stare PCB do pracy w nowej konfiguracji. Nie tylko dodano nowe połączenia za pomocą srebrzanki, ale również dokonano licznych cięć ścieżek na płytce drukowanej.

Cartridge może pracować w dwóch trybach:

• jako cartridge o rozmiarze 16KB, zajmujący obszar $8000-$BFFF

• jako cartridge o rozmiarze  8KB, zajmujący obszar $A000-$BFFF

Jeden z przełączników wybiera właśnie tryb pracy carta, tzn. 16kB lub 8kB,. Drugi z przełączników działa tylko i wyłącznie w trybie gdy wybrany jest tryb 8kB, i służy on do wyboru jednego z dwóch obrazów 8kB umieszczonych w pierwszej połowie pamięci EPROM. Także gdy cart pracuje w trybie 16kB położenie drugiego z przełączników nie ma żadnego znaczenia.

Gdy zacząłem rysować schemat tego carta i analizować jego pracę, szybko okazało się że ignorancja konstruktora sięgnęła zenitu i z niedowierzaniem analizowałem tę sytuację kilka razy, ale okazało się że gdy cart pracuje w trybie 8kB przełączenie przełącznika od wyboru 8-kilobajtowego banku powoduje zwarcie linii S4 do masy. Należy tu przypomnieć że linia S4 jest linią wyjściową z punktu widzenia Atari. W przypadku tego carta linia ta została podłączona do linii adresowej A13 pamięci EPROM. W sytuacji gdy cart pracuje w trybie 16kB, wszystko jest OK, w zależności od stanu tej linii zostaje zaadresowany odpowiedni kawałek pamięci EPROM, tak aby był on prawidłowo mapowany w obszar $8000-$9FFF lub $A000-$BFFF. Nie wiem co kierowało autorem tego rozwiązania ale wybór banku w trybie 8K jest realizowany właśnie przez przełączenie stanu linii A13 (przełącznikiem nr 2) i wszystko byłoby OK gdyby nie fakt że linia ta cały czas (mimo zmiany konf. na 8K) nadal zostaje podpięta do S4. Autor rozwiązania uznał że warcie przełącznikiem tejże linii to masy będzie wystarczające aby osiągnąć przełączenia banku. Nie sądzę by MMU w atari było w z tego powodu zadowolone.

Oczywiście nie mogłem pozwolić na pozostawienie tego w takim stanie, a ponieważ w carcie dodano drugi układ scalony (7403) i dwie bramki w nim nie były wykorzystane postanowiłem wykorzystać ten fakt i wykorzystać te bramki do bezpiecznej realizacji założonej przez autora funkcji. Oczywiście na schemacie który zamieszczam dodaję już tę modyfikację składającą się z bramek U1A, U1B oraz rezystora R1.

Dwie pozostałe bramki układu 7403 zostały wykorzystane do zbudowania układu zabezpieczającego przed klonowaniem cartów z oprogramowaniem firmy ATARES. Pirat powielił ten układ dla bezpieczeństwa. Oryginalne oprogramowanie od ATARES sprawdzało obecność tego układu i gdy nie był on obecny, loadery i procedury ładujące nie działały poprawnie. Nie wiem czy soft zawarty w tym carcie został pozbawiony zabezpieczeń tego typu, bo tego nie sprawdzałem, jednak tym razem układ został podłączony i dba o to aby bit D6 magistrali danych przy każdym odczycie z obszaru $D5xx był zawsze wyzerowany.

Po poprawkach płytka carta wygląda tak:

góra:

spód:

^^^ jak widać wszystkie połączenia wykonane srebrzanką zostały zastąpione połączeniami wykonanymi kynarem, zostały dodane kondensatory filtrujące przy układach TTL i wprowadzone poprawki związane z linią S4.

Pora zatem chyba zaprezentować już schemat carta z poprawkami o których pisałem wyżej:

^^^ Po otwarciu obrazka w nowej zakładce będzie on zaprezentowany w wyższej rozdzielczości. Jak zwykle do pobrania również wersja wektorowa (PDF): Shogun Blizzard 32K Multi Cart.

Cóż można jeszcze dodać w tym temacie? Na chwilę obecną wydaje mi się, że temat został wyczerpany, gdyby mi się coś przypomniało będę dokonywał edycji tego postu. Pozostało tylko udostępnić archiwum z zawartością pamięci EPROM tego carta: Shogun Blizzard 32K Multi Cart

co w środku archiwum?

• shogun_blz32k.bin - cała zawartość pamięci EPROM (32kB)

• shogun_phnx_16k.bin - wydzielona część (16kB) zawierająca obraz carta Phoenix 1.0 by Hurek

• shogun_blz1_8k.bin - wydzielona część (8kB - bank #0) zawierająca obraz "Turbo Blizzard"

• shogun_blz2_8k.bin - wydzielona cześć (8kB - bank #1) zawierająca obraz "Blizzard Cartridge"

Jak widać powyżej oprócz zawartości całej kostki wydzieliłem poszczególne obrazy cartów z całego obrazu, a to dlatego aby możliwe było uruchomienie tego pod emulatorem. Jako że żaden z emulatorów nie wspiera cartów tego typu (z manualnie przełączanymi wajchami i typami) poprawne uruchomienie pliku "shogun_blz32k.bin" nie jest możliwe, ale wydzielone pliki jak najbardziej można uruchomić, oczywiście w przypadku 16kB pliku wybieramy typ carta "Blizzard 16k", natomiast w przypadku plików 8kB wybieramy typ carta "Phoenix 8kB".

Na koniec jeszcze tylko hashe SHA256 plików z archiwum:

4b7dfb2f715a805f2a33ed6f0e9aedc9768c2dccf2561f3fa2065a8cb14113ac  shogun_blz32k.bin
8c94594dcd7f350ba48fe90dcdc5ff194e9cc2c73c59d623137f7b30f3dfdab4  shogun_blz1_8k.bin
f978d9102cd361c737f61fa07b3c105ba8fc90dd1b4927de72e6a62cca03aa85  shogun_blz2_8k.bin
aa7a0f657cfb649d1841a84fff95a6ac5af0688b6b7e6742647040eef4618e8e  shogun_phnx_16k.bin

EDIT1: nie wiem czy wydzielone pliki uruchomione pod emulatorem będą działać poprawnie, a to ze względu na to że nie mam pewności czy soft nie sprawdza obecności układu "zerującego" bit D6 w przypadku czytania z obszaru $D5xx. Wybaczcie ale nie miałem już siły, chęci ani czasu aby to dokładnie sprawdzić. Myślę że zainteresowani tematem będą w stanie to szybko zweryfikować.

EDIT2: Cart w trybie 8K tak naprawdę nadal działa jak cart 16K (linie RD4 i RD5 są zwarte, więc MMU w obszar $8000-$9FFF) zawsze mapuje zawartość "cartridge", jednak dekoder sygnału CS w przypadku pracy w trybie 8K nie generuje poprawnego sygnału CS w przypadku adresowania obszaru $8000-$9FFF, przez co w tym obszarze pojawiają się losowe śmieci (w serii XE, brak pull-up na magistrali danych). Tak naprawdę w niczym to nie przeszkadza bo cart po przepisaniu danych do niższych obszarów pamięci zostaje kompletnie odłączony. Można było to oczywiście rozwiązać, ale autor carta nie przejmował się bym, bo w niczym to nie przeszkadzało, a wymagałoby to od niego dodatkowego nakładu pracy.

jaki koszt części? to są jakieś drobiazgi, nawet nie ma jak tego wycenić/liczyć, bo to ze "starych" zapasów :)

co do zdjęcia faktycznie dwa razy podlinkowałem ten sam plik, poprawione.