Dokładnie tak jest, ale pod warunkiem że tor odczytu wolniejszego systemu turbo jest dostosowany do przenoszenia wyższej częstotliwości, którą generuje szybszy system turbo. Niektóre interface do wolniejszych systemów turbo mogą mieć tak dobraną charakterystykę wzmacniacza wejściowego aby nie przenosiła częstotliwości większych niż potrzeba (np. aby pozbyć się zakłóceń, ew. odfiltrować szum z otoczenia, etc).

W przypadku niektórych systemów (z tego co pamiętam np. w TurboROM) wymienia się trochę kondensatorów w stopniu wejściowym a do tego zmienia się rezystory w pętli sprzężenia, czy inne ustalające punkt pracy wzmacniacza wstępnego.

Hej!

Kurczę, to zupełnie jakoś mi to umknęło... ale skoro mówisz że działa to będę musiał sprawdzić... kiedyś próbowałem na jakimś "rozklekotanym" XC12 z Turbo2000F (w końcu lina odczytu ta sama co Blizzard)... ale miałem problemy właśnie z pasmem przenoszonym przez tor odczytu... ale sprawdzę na jakimś magnetofonie w lepszym stanie... być może wtedy miałem kasetę z dość niskim poziomem zapisu. Niemniej jednak to kwestia do której warto wrócić :) Zrobię testy i dam znać ;)

Dobry Wieczór,

Dawno nic nie było o cartach, prawda? :D A do tego temat zboczył na meandry alternatywnej rzeczywistości... zatem pora trochę powrócić do głównego wątku... Niestety dziś w sumie nic odkrywczego i nowego, bo cart był wcześniej opisywany w tym wątku: Turbo HIT. Podobny cart znajduje się w kolekcji uicr0bee, a opisuję go po pierwsze niejako z "kronikarskiego obowiązku" ;-) a po drugie... ta wersja carta sprawiała problemy (startowała losowo, zawieszała się) ... więc przedstawię niejako historię choroby.

zestaw oprogramowania zapisany w pamięci EPROM tego carta prezentuje się tak:

UWAGA!!! Na ekranie tytułowym autor tej "składanki" zeserwował na pozycjach "1" i "2" menu napisy "K.S.O." ... niestety dla oczekujących że to oprogramowanie dla "KSO Turbo 2000", czeka rozczarowanie... bowiem po uruchomieniu tego oczom użytkownika ukaże się zwykły "blizzardowy" Turbo K.O.S. Literówka? Błąd? Celowe działanie? Nie wiem... sam dałem się na to "złapać", jak Dely po raz pierwszy zaprezentował tego carta i myślałem że to będzie jakiś soft do "czytania" programów w standardzie KSO Turbo 2000 na magnetofonie z interface Blizzard ;)

1) zawartość pamięci EPROM: Blizzard Turbo HIT.bin.7z

blizzard_hit.bin:

MD5   : 1bf8c35282db822851939a21bd1ab07a 
SHA256: 35ebf1f26c9ba8f9028ce3de86c4d6490ea1e3217b53768f6833fdbd096c92e2

Co prawda zawartość jest identyczna z tą którą można znaleźć w wątku o Turbo HIT od Dely-ego, ale dla porządku zamieszczam tutaj drugi dump z tego egz. carta. Jest to też swego rodzaju weryfikacja że cart jest zrzucony bez przekłamań.

I jeszcze wielkie podziękowania należą się koledze "Krótkiemu", który to dodał emulację/obsługę tego carta do Atari800. Nie miałem mu okazji podziękować we wcześniejszym wątku o Turbo HIT, ponieważ jego post o tym fakcie przeczytałem dość długo po tym jak został napisany.

2) wersja XEX dająca się uruchomić spod DOS-a lub dowolnego loadera plików binarnych: blizzard_turbo_hit.xex.zip

Skoro już drugi raz trafił mi się ten cart i z tym miałem problemy... to pomyślałem że zajrzę w kod... i przy okazji sprawdzę czy nie dało by się zrobić wersji XEX. Okazało się ze jest to zupełnie banalne, bo cart koniec końców po starcie całe 32KB przepisuje do pamięci RAM, po czym odłącza się i pokazuje menu. Takie podejście pozwoliło bardzo szybko zrobić wersję XEX.

3) Schemat:
do pobrania również wersja wektorowa: Blizzard_HITv1.1 (PDF)

Pamięć EPROM w cartridge ma 32KB. Mapowana jest w obszarze $A000-$BFFF, podzielona jednak na cztery banki po 8K. W tej wersji karta znajduje się 74LS00 (4 brami NAND), oraz licznik 7493. Licznik steruje liniami adresowymi A13, A14 pamięci EPROM (wyjścia QB, QC licznika). Wyjście QD jest zeruje przerzutnik RS złożony z bramek U3C, U3D.

Wejście CLKB licznika zostało podpięte pod ~CCTL, a to powoduje że dowolne odwołanie do $D5xx powoduje zadziałanie licznika i włączenie banku. Gdy licznik doliczy to "4", wyście QD zostanie ustawione na "1", a to spowoduje skasowanie przerzutnika RS i odłączenie carta.

W przypadku tego egzemplarza obserwowałem że cart uruchamia się losowo, czasami bez aktywności linii ~CCTL licznik zliczał  jakieś serie impulsów i cart odłączał się. Problem rozwiązało dodanie małego kondensatora 100nF na zasilaniu 7493, oraz "barbarzyńskie" rozwiązanie w postaci dołożenia kondensatora 680pF na linię ~CCTL. Problemy zniknęły tak szybko jak się pojawiły... więc dodałem te pojemności na schemacie, oraz oznaczyłem schemat wersją 1.0a (chcących to porównać z wersją carta od Dely-ego zapraszam do tego konkretnego postu w wątku o Turbo HIT).

Ten cart był zalany toną kleju :( próba otwarcia obudowy skończyła się jej zniszczeniem, poklejone było wszystko co się dało, krawędzie obudowy, PCB do obudowy oraz zamiast śruby była tona kleju w miejscu kołka mocującego/tulejki w którą wkręca się śrubę. Obudowa na szczęście typowa, wymieniłem na identyczną, oczywiście nic nie kleiłem, a skręciłem jedynie obudowę na śrubę. Cart wygląda teraz jak nowy :D

PCB ma przewidziane pady do których montuje się przycisk resetujący elektronikę carta, jednak w tej wersji nie był on obecny, nie poprawiałem zatem oryginału i konstrukcję zostawiłem w takim stanie jakim zastałem.

Sam cart prezentuje się tak:

PCB, góra:

PCB, spód:

EDIT@2025.08.13: zaktualizowano linki (+HTTPS)
EDIT@2026.03.19: Poprawiono błędy na schemacie.

@piwkoo: niezłe blizzardowe "combo" wyprodukowałeś! :)  fajnie że podzieliłeś się swoją pracą. takie dzielenie się projektami to propagowanie wiedzy i to się chwali :]

UWAGA!!! Panowie! Informacja dla zainteresowanych cartem Turbo Toolbox II, o którym pisałem w tym poście. Odwaliłem tam niezłą kichę związaną z błędną zawartością pliku w wersji oryginalnej. Dzięki koledze JLS z tego forum, sprawę udało się rozwikłać a błąd usunąć... szczegóły w oryginalnym poście.

Dla zainteresowanych tym jak mogło dojść do zamiany banków śpieszę z wyjaśnieniem; gdy dostaję do cartridge do archiwizacji i jest on zupełnie sprawny i nie wymaga naprawy, poprawek czy modyfikacji, to nigdy nie ingeruję w jego płytkę, tzn. nie wylutowuję EPROM-a aby go zgrać, ponieważ chcę zachować stan oryginalny płytki, etc. Wyznaję zasadę minimalnej ingerencji w powierzony do analiz materiał. Tak cart zgrywam wkładając go do Atari i używając systemu QMEG, ręcznie przełączam kolejne banki i dokonuje zapisu na dyskietkę (w tym wypadku wirtualną, używam AspeQT) używając do tego celu komendy wbudowanej w MLM (monitor pamięci w QMEG).

W tym wypadku gdy zgłosił się do mnie JLS i opisał problem, bałem się że zrobiłem jakiś błąd na schemacie, ale ponieważ wersja pliku przeorganizowana dla Blizzard32K działała, coś innego musiało być na rzeczy... no i było... patrząc na własny schemat pomyliłem linie A13 i A14 i przez to jak składałem wynikowy plik, to banki o adresach "01" i "10" zostały zamienione... (założyłem domyślnie że ~Q4=A14 a nie ~Q3=A13... a tymczasem jest odwrotnie :P, co ciekawe na schemacie błędu nie popełniłem... a zrobiłem go tylko generując plik wynikowy). Wszystko w poście o Turbo Toolbox II zostało już poprawione i zaktualizowane, oczywiście wcześniej poprawkę JLS sprawdził na swojej replice carta i działa ona OK! :)

Za poświęcony czas i pracę wykonane nad repliką carta, WIELKIE dzięki dla JLS raz jeszcze! :D

Następny cart, ale tym razem to niejako formalność i być może trochę nowsza wersja/rewizja carta który był już opisywany przeze mnie w tym wątku: Blizzard Turbo - ponownie. W owym wątku można przeczytać o carcie dla blizzarda o nazwie "Phoenix 1.0". W tym wątku również przedstawię ten cart, jednak w wersji która znajduje się w kolekcji uicr0bee. Oprogramowanie zawarte w carcie prezentuje się tak:

Dlaczego przedstawiam ten cart ponownie, skoro już był opisany w dużo wcześniejszym wątku? I do tego dlaczego nadaję mu inny numer (1.0a) wersji?

Po dokonaniu zrzutu zawartości EPROM porównałem ją ze starą wersją celem weryfikacji czy poprzedni "zrzut"  był na pewno dobry... okazało się że są różnice... obawiałem się że któryś obraz może być uszkodzony... jednak szybki rzut okiem pozwolił stwierdzić iż różnicę występują tylko i wyłączne w napisach zawartych w dwóch microloader-ach. Ani jeden bajt kodu się nie różni.

W stosunku do wersji 1.0a, to w wersji 1.0 widać różnice w napisach w w Microloader 1.0 oraz Microloader 2.0:

I można się dowiedzieć również że KNS i ATARES to chyba ta sama firma, ponieważ jak widać na załączonym obrazku możemy zobaczyć tam: KNS "ATARES". Coż w takim razie znaczy skrót KNS? ;)

Dodatkowo wersja cartridge od uicr0bee, miała włożony dwa razy większy EPROM (27C256 zamiast 27C128)... jednak najbardziej znaczącą linię adresową (A14) miała na stałe przypiętą do +5V (EPROM 27C128 ma na tym pinie sygnał VPP, który tez powinien być podłączony do +5V przy normalnej pracy pamięci). Postanowiłem sprawdzić jednak co znajduje się drugiej niewykorzystanej połówce  połówce EPROM... ciekawość nie dawała mi spokoju... więc odczytałem cały EPROM ... okazało się że EPROM zawiera dwie identyczne kopie oprogramowania :) Tym razem żadnych niespodzianek ani ukrytych ciekawostek :)

Jednak ze względu na różnicę w napisach, oraz to że cart wydaje się nowszy... (zastosowana większa pamięć, zapewne nie były już wtedy łatwo dostępne 27C128 lub producent ujednolicał/unifikował listę komponentów a różnica w cenie była niewielka to zdecydował się na stosowane jednakowych pamięci 27C256. Płytkę drukowaną miał przystosowaną do obu typów pamięci (poprzez zworki i mostki które można naciąć aby przerwać dane połączenie w zależności od potrzeb konfiguracyjnych) ... postanowił opublikować również i tę wersję carta, dodając do jej oznaczenia literkę "a" na końcu, zatem kontynuując już standardową procedurę:

1) zawartość pamięci EPROM:

- dla pamięci EPROM 27C128 o rozmiarze 16K: atares_phoenix_1.0a_(27C128).bin.7z
- dla pamięci EPROM 27C128 o rozmiarze 32K: atares_phoenix_1.0a_(27C256).bin.7z

Plik dla pamięci 27C256 to nic innego jak powielony dwa razy i plik dla pamięci 27C128. Normalnie wystarczyłoby zaprogramować tylko górną połówkę pamięci 27C256 zawartością pliku dla pamięci 27C128, ale skoro producent carta zrobił dwie kopie to zachowując zgodność z oryginałem też tak czynię.

atares_phoenix_1.0a_(27C128).bin:

MD5   : 32bd6793588fdc858485a1fd755bedc8
SHA256: 058c7ec6c59a4f2082c83d9616ba7b8c6379c22b66013d979004cbc4fb051ace

atares_phoenix_1.0a_(27C256).bin:

MD5   : 6d61b9641b8351fadc27b43882c5af05
SHA256: 761aa1237b062c338f4358152e5dacaee438beb080ade4ea329354e0bba93921

2) wersja XEX dająca się uruchomić spod DOS-a lub dowolnego loadera plików binarnych: atares_phoenix_1.0a.xex.zip

3) Schemat:

Do pobrania również wersja wektorowa (PDF): Phoenix 1.0a

UWAGA!!! Poprzednia wersja schematu tj. 1.0 zawierała błąd! Poprzez moje niedopatrzenie zostały zmienione miejscami sygnały ~CCTL i ~RST przy przerzutniku RS. Błąd zgłosił mi Piguła/Shpoon, za co mu serdecznie dziękuję! Dzięki temu mogłem poprawić schemat.

Jest to typowy 16KB cartridge mapowany w obszar $8000-$BFFF, beż żadnego przełączania banków, za to z możliwością odłączenia go na drodze programowej poprzez dowolne odwołanie do obszaru $D500-$D5FF. To właśnie z bramek U2A i U2B zbudowano przerzutnik realizujący tę funkcję. Z bramek U2C, U2D zbudowano układ którzy aktywuje sygnał Chip Enable (~CE) pamięci EPROM w chwili gdy zostanie wykrywa aktywność w obszarze $8000-$9FFF (sygnał ~S4) lub w obszarze $A000-$BFFF. Dodatkowo sprawdzany jest sygnał R/~W... i aktywacja pamięci EPROM nastąpi tylko i wyłącznie gdy CPU będzie dokonywał odczytu.

I tu jedna drobna uwaga... to jeden z niewielu cartów z tamtych czasów, który uwzględnia sygnał R/~W... w przypadku większości do tej pory zaprezentowanych tutaj cartów, sygnał R/~W był ignorowany i można było próbować dokonać zapisu do pamięci EPROM (oczywiście nieudanego) a jedyny w ten sposób osiągnięty efekt to kolizja na szynie danych (CPU wystawiało swoje informacje, pamięć EPROM swoje). Ale jak widać po poprzednich rozwiązaniach oszczędzano każdą bramkę i zakładano że nikt nie będzie pisał w obszarze carta gdy ten włączony (aktywny sygnał RD4,RD5).

cart prezentuje się tak:

PCB góra:

PCB spód:

Skoro wszyscy zgłaszają się z chęcią zakupu, mimo że Simius jeszcze nic o tym nie wspomina, to czynię to również i ja ;) Jestem zainteresowany 1 szt.

Tak jak pisałem wcześniej robię dokładnie tak samo, świetlówka Philips TUV 6W, taka:

Po 2-3 minutach EPROM czysty... no chyba że był zaprogramowany solidnie (tzn. nie algorytmem typu "smart" tylko "slow"), wtedy 5 minut i taki EPROM również jest czysty.

Pytałem o długość fali, bo...

...  nie sądzę aby długość fali musiała być tak dokładna... ale zapewne bo musi być coś z zakresu UV-C.

Przy tej ilości banków to chyba nie ma sensu robić licznika, wygodniej będzie chyba wziąć jakieś np. 74LS273 lub coś podobnego i zrobić z tego 1-bajtowy "rejestr/port" do którego będzie można zapisać wartość adresując $D5xx, a skoro rejestr będzie miał 8bit, to 7 bitów podłączysz pod pozostałe linie adresowe EPROM, a pod bit 8 podepniesz RD5. W ten sposób jednym zapisem pod $D5xx będziesz mógł wybrać bank, a także odłączyć cart zupełnie w razie potrzeby. Tak zrobiłem projektując kiedyś cart do Yoomp!. Sprawdził się doskonale, w dodatku ma wsparcie również z poziomu emulatora.

tzn. żeby była jasność ;) nie poprawiłem tego w obrazach udostępnionych tutaj... sprawdziłem tylko co siedzi tam w kodzie i pamięci (ile jest faktycznie poziomów), a testowałem wszystko po wprowadzeniu poprawki z palca pod emulatorem. Ale sądzę że warto poprawić tą grę i dodać jakiś trainer plus opcję pomijania poziomów ... ale to już trochę później ;-) Jeszcze parę cartów i magnetofonów zostało :D

EDIT1: Jeżeli ktoś chce sobie przetestować to pod emulatorem, np. altirra to gdy uruchomi się gra, wciskamy F8 wchodzimy do debuggera i na konsoli piszemy:

e 3a7a 93

^^^ to poprawka dotycząca ilości plansz. Po wpisaniu aby uruchomić znowu emulator wciskamy ponownie F8 (aby wyłączyć dodatkowe okna które się pojawiły po wciśnięciu F8, wystarczy w menu "debug" odznaczyć opcję "enable debugger"

jeżeli ktoś chce pominąć jakiś poziom to wystarczy że na danym poziomie, uruchomi debugger i na konsoli napisze:

e ed 0

^^^ taki zabieg można wykonać w przypadku każdego poziomu, powoduje to zakończenie aktualnego i przejście do następnego poziomu.

Daj znać czy się udało i jeżeli się uda to jakiego typu UV LED użyłeś (długość fali, emitowana moc promieniowania).

EDIT2: wychodzi na to że się da... tylko przy 5mW mocy cała operacja trwa parę godzin :) więcej pod adresem: improvising an eprom-eraser.

Idąc za ciosem i kontynuując wątek cartów Blizzarda, a zarazem streszczając się, bo już zanudzam i spamuje ostatnio forum tematem cartów turbo ;) zaprezentuje dziś kolejny cart z kolekcji uicr0bee, a będzie to kolejny piracki klon carta Blizzard 8K, podpisany przez kogoś o nicku "SHOGUN". Soft zawarty w carcie ma usunięte, bądź pozmieniane napisy... a prezentuje się tak:

Jak zatem widać jest to kolejny klon, podobny do tego który był opisany w tym poście.

Przechodząc do do sedna sprawy:

1) Zawartość pamięci EPROM: blizzard_8k(shogun).bin.7z

blizzard_8k(shogun).bin:

MD5   : 83c3164053ae86615426a5ff60ee6269
SHA256: 8c94594dcd7f350ba48fe90dcdc5ff194e9cc2c73c59d623137f7b30f3dfdab4

2) wersja XEX dająca się uruchomić spod DOS-a lub dowolnego loadera plików binarnych: blizzard_8k(shogun).xex.zip

3)  Schemat: wektor (PDF), raster color (PNG), raster grayscale (PNG).

Jak widać budowa standardowa. Cartridge o pojemności 8KB, mapowany w obszar $A000-$BFFF. Można go odłączyć na drodze programowej poprzez dowolne odwołanie do obszaru $D500-$D5FF. Przerzutnik RS realizujący odłączenie cartridge zrealizowano również w standardowy sposób, czyli na dwóch bramkach NAND. Co ciekawe na płytce istnieje też kawałek układu zabezpieczającego skopiowanego z oryginalnego carta Blizzard KNS/Atares, jednak koniec końców nie został on podłączony do linii D6 magistrali danych.

Cartridge prezentuje się tak:

PCB góra:

PCB spód:

EDITED@2025.08.13: http to https links changed.