hehehe.... fakt :) Produkty by "Stecu/The Distals"* są nie do podrobienia i nie do odkucia ;P

aby ludzie wiedzieli o czym mówisz pozwolę sobie pokazać przykład, oto "Happy Freezer" zamontowany w moim 130XE:

https://pigwa.code32.org/aa/freezer.jpg

^^^ dzięki temu powstał Overmind, Bitter Reality, oraz dużo... dużo innych mniejszych i większych produkcji ;) To jeszcze były czasy kiedy cross-development dopiero raczkował :)

*) (c) by Miker ;-)

Kolejny cart z kolekcji na tapecie.Tym razem 4KB cart zawierający soft dla "Turbo Blizzard":

https://pigwa.code32.org/uicr0bee/carts/Blizzard_4k/scr/blizzard4k_a.png https://pigwa.code32.org/uicr0bee/carts/Blizzard_4k/scr/blizzard4k_b.png

https://pigwa.code32.org/uicr0bee/carts/Blizzard_4k/scr/blizzard4k_c.png

i tradycyjnie już:

1) zawartość pamięci EPROM: Blizzard 4K Cartridge.

blizzard_4k.bin:

MD5   : cdcc5d862fda9c8f37050c31038a64ba
SHA256: 583c051c527bf133a4bd8c0b46476897c10bf2d130c8650bfcf698632755dc76

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

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

Tym razem chyba "dla zmylenia przeciwnika", przerzutnik RS wykonany na bramkach NOR, a "zabezpieczeniem" przed kopiowaniem miało być chyba starcie napisu z układu scalonego ;) to takie "security by obscurity*" z tamtych czasów.

Sam cart prezentuje się tak... i jak widać jest to kopia zabezpieczona przed kopiowaniem :D
https://pigwa.code32.org/uicr0bee/carts/Blizzard_4k/photo/P1070318.JPG

PCB spód:
https://pigwa.code32.org/uicr0bee/carts/Blizzard_4k/photo/P1070321.JPG

PCB góra:
https://pigwa.code32.org/uicr0bee/carts/Blizzard_4k/photo/P1070315.JPG

*) https://xkcd.com/257/

EDITED@2025.08.13: http links updated to https

1,228

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

hej!

No to wygląda na to że D6 w tej konstrukcji carta nie zawsze się odczytuje jako "zero".

Widać to pięknie na screen-ie z 800XL, D6 losowo przyjmuje wartość "1". Na podglądzie tam gdzie są ciemne paski na D6 pojawiają się również zapewne losowe kropki.

W przypadku XE robi się jeszcze ciekawiej :) Błędne odczyty na D6 pojawiają się tylko przy czytaniu adresów $d500 oraz $d501 dla innych adresów, wychodzi na to że zachowanie układu jest prawidłowe dla pozostałych adresów. Pozostałe bity (poza D6) są losowe w przypadku XE, ale tak ma być. Jakieś ciekawe zależności czasowe jakieś tam zachodzą.

Ta dioda która robi za "emulator" wyjścia open-collector to pamiętasz jakiego typu jest? No i pytanie jakiej pojemności są te kondensatory SMD (szczególnie ten dołożony pomiędzy CCTL a GND)?

Piszę "kondensatory" bo widzę tam jeszcze jakieś dwa kondensatory SMD dołożone, nie bardzo widzę na zdjęciach gdzie są podłączone dokładnie.

Można spróbować zmienić diodę na szybszą i koniecznie sprawdzić trzeba ten kondensator pomiędzy CCTL a GND, powinien mieć pewnie ponad 500pF.

u mnie to wygląda tak (płyta 130XE, pamięci 1bit)

http://seban.pigwa.net/atari/bus_test/fast_d6.png

no i tak to powinno wyglądać.

1,229

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

@link... cholerne prawa dostepu :( moja wina, już poprawiłem. Powinno się dać pobrać już.

@foty: no cart jest innej konstrukcji... już chyba widzę co jest grane, nie masz w swoim carcie bramek Open-Collector, tylko zwykłe 7400. Widzę również dwa kondensatory SMD -> to na pewno jest jakaś późniejsza modyfikacja (tzn. ktoś w tym grzebał i robił jakieś zmiany). Jak uruchomisz drugi test, to wszystko będzie wiadomo... pewnie wyjdzie że w tej wersji carta nie ma tego zerowania D6 przy odczycie $d500-$d5ff, wnioskuję to ze zwykłych bramek.... ale to w wolnej chwili dokładniej przeanalizuję, bo być może ktoś zrobił "zasymulował" wyjście typu open-collector diodą którą widzą na zdjęciach... ale możliwe też jest to że dioda to kawałek układu resetu :)

1,230

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

Hej!

Powiem Ci że to są bardzo ciekawe wyniki :) Najbardziej mnie zastanawia "6,R,s"... coś zdrowo musiałem w kodzie spierniczyć bo ten zapis sam sobie przeczy :) "bit Schrödingera" cholerka... stabilnie losowy :P Aż sprawdzę na swojej 800XL.

Natomiast twój wynik z 65XE też jest dziwny, niby widać że twierdzi że na bicie #6 jest "0", jednak na dole stwierdził "u", co wypisuje wtedy kiedy wyniki kolejnych serii odczytów różnią się.

Czy przy innych trybach odczytu (nie tylko double ex-or) wyniki są podobne?

U mnie z 65XE jest jak widzisz "6,0,s". I sądziłem że tak będzie u Ciebie, martwią mnie te dziwne wyniki... pytanie czy ja coś spierniczyłem w kodzie testera, czy faktycznie masz jakieś dziwne zachowanie swojego egzemplarza carta. Jednak składając to w całość z Twoimi problemami z odczytem danych, coś może być na rzeczy... czyli pewnie coś z tym D6 nie do końca dobrze... a i pewnie jakiś babol się znajdzie w kodzie testera.

Dziwią mnie Twoje wyniki z 800XL... szczególnie to że w oknie "preview" widać praktycznie wartości różne od $FF, a powinno być $FF jak drut wszędzie, a to chyba pojawia się sporadycznie.

Możesz wrzucić zdjęcia PCB (góra, dół) może uda się coś wypatrzyć.

EDIT:. Jak będziesz miał chwilę uruchom proszę ten program u siebie (oczywiście gdy cart będzie obecny w slocie): fast_d6.xex. Jak będzie Ci się chciało to zrób test na XE i XL.

1,231

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

problemem jest tylko mechanika, tzn. dostosowanie/wycięcie obudowy. same laminaty są gotowe i to od dawna, komponenty do montażu też leżą i czekają. montaż płytek zrobię jak tylko ogarnę sensownie obudowy.

http://seban.pigwa.net/aa/slt_sid_pcb.JPG

1,232

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

spoko! mam nadzieję że się przyda i pomoże w rozwiązaniu problemu, albo chociaż w stwierdzeniu że nie tu leży problem  :)

1,233

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

@stryker: szanse oczywiście są, ale przyznaję że klika nieudanych prób współpracy różnego rodzaju firmami mającymi zająć się kwestiami mechanicznymi spowodowały że przestałem uważać temat za pilny, szczególnie że miałem inne problemy na głowie. Na pewnym etapie uznałem że dość wkładanie w to kolejnych środków i czasu, bo są inne priorytety. Nie chcę tutaj obiecywać żadnych kolejnych terminów bo nie wiem jaka przyszłość mnie czeka, wrócę do tematu po nowym roku i zobaczymy co w kwestii obudowy da się zrobić tym razem.

1,234

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

Hej!

Proszę, oto bardzo na szybko sklecony program analizujący zachowanie magistrali danych w obszarze $D500-$D5FF: DATA BUS Analyzer. Nie jest to jakieś super specjalizowane narzędzie, jednak spełnia swoje zadanie.

Po jego uruchomieniu gdy tylko cartridge blizzard będzie umieszczony w gnieździe, powinieneś zobaczyć coś takiego:

http://seban.pigwa.net/atari/bus_test/bus_analyzer.jpg

W linii "bit patterns" na pozycji #6 powinno widnieć "0", a poniżej pod nim litera "s", oznaczająca iż bit jest stabilny, tzn. każdy odczyt daje stan określony wyżej, czyli w tym wypadku "zero". Po wyjęciu z portu cartridge-a zobaczysz tam w zależności od modelu komputera albo "R" i "u" (seria XE) albo "1" i "s", (seria XL). Różnice pomiędzy serią XE a XL wynikają z obecności tzw. pull-up na magistrali danych, czyli rezystorów podciągających magistralę to +5V.

Dla prawidłowego działania cartridge blizzard wymagane jest "0" i "s" na bicie #6.

1,235

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

To jeżeli masz realny hardware wyglądający podobnie jak ten na zdjęciach w wątku o KNS BIG 2.0, i zapewniający zgodność z zerowaniem bitu D6 przy odczycie z obszaru $D500-$D5FF wszystko zatem powinno działać jak należy.

W wolnej chwili przygotuję jakieś oprogramowanie testujące które sprawdzi czy na pewno wszystko ze sprzętem OK, to sobie sprawdzisz czy aby hardware carta na pewno pracuje poprawnie.

1,236

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

UWAGA !!! Coś co było podejrzewane jako zabezpieczenie (zerowanie bitu D6 przy odczycie z obszaru $D500-$D5FF), takim zabezpieczeniem się okazało. Plik .XEX udostępniony przeze mnie nie będzie działał prawidłowo po uruchomieniu. Plik z zawartością EPROM będzie działał poprawnie jedynie na prawdziwym sprzęcie z odtworzonym mechanizmem zapewniającym iż bit D6 magistrali danych będzie zawsze wyzerowany przy dowolnym odczycie z obszaru $D500-$D5FF.

Gdy się zorientowałem w czym rzecz, miałem dokonać poprawek w obu plikach, jednak tak się zbierałem do tego, w końcu o tym zapominając, i okazało się że jakiś czasu temu kolega FUJI poprawił co potrzeba, cała walka i jej opis można śledzić w tym wątku na AtariOnline.

Wątek zawiera poprawione wersje plików (XEX, ROM) one będą działać już poprawnie.

1) poprawiona wersja XEX: KNS_big2_cracked_by_FUJI.xex
2) poprawiony obraz Blizzard 4.0 BLZ_40_cracked_by_FUJI.rom

ps1) oba linki prowadzą do portalu AtariOnline.

ps2) przy okazji zabawy z budową takiego cartridge, pomocy się może okazać DATA BUS Analyzer, więcej informacji w tym wątku.

http://seban.pigwa.net/atari/bus_test/bus_analyzer.jpg

1,237

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

Cześć!

No bo jest niestety lipa. Jak się okazało cartridge miał zabezpieczenie "anty pirackie", polegało ono na tym że wykorzystało mechanizm z zerowaniem bitu D6 w chwili odczytu dowolnej komórki z przestrzeni $D500-$D5FF. Wyrażałem swoje wąpliwości w wątku o tym carcie, o tutaj. Miałem się nawet zabrać za analizę i poprawę tego kodu, ale na atarionline.pl ktoś napotkał ten sam problem co Ty i i kolega FUJI postanowił go rozwiązać własnoręnie, cały wątek do poczytania tu.

FUJI udostępnił "crackowaną" wersję pliku XEX oraz poprawiony ROM (posty #24 i #25 w wątku na AtariOnline).

Muszę zrobić porządek w wątku na AtariArea i uaktualnić linki, aby nikt już nie wpadał w pułapkę związaną z obrazami bez "poprawek". ROM z wątku na AtariArea będzie działał poprawnie jedynie realnym hardware zbudowanym w/g schematu który tam udostępniłem. Plik poprawiony przez FUJI-ego będzie działał już wszędzie.

Masz rację, mój błąd... całe życie widziałem tam "Wojciech Zabłotny". Poprawię w wiki i tutaj w wątku. dzięki za czujność!

ps) w wiki już zdążył Miker poprawić :)

1,239

(421 odpowiedzi, napisanych Fabryka - 8bit)

Dziś otrzymałem swój egzemplarz od Duddiego... WIELKIE DZIĘKI! I ogromny szacunek ja wykonaną pracę, za jakość, za dbałość o szczegóły i wykonanie książki! Warto było czekać na coś takiego! Dzięki raz jeszcze! Naprawdę doceniam to co robisz! :)

dzięki za weryfikację! poprawię i u siebie aby było tak samo. będę musiał ten dziwny "reset" zmontować jakoś na szybko na płytce uniwersalnej i zobaczyć jak się to zachowa jak potraktuje się to serią ultra-szybkich dostępów do obszaru $D500-$D5FF.

Hej!

Dzięki za uwagi i sprawdzenie elementów, ale mam jednak wątpliwości...

pancio.net napisał/a:

Pomiędzy rezystorami jest elektrolit (oznacza to, że elektrolit jest pomiędzy /CCTL i GND)

To chyba nie jest możliwe, ze zdjęcia płytki wynika moim zdaniem coś innego. To by nie mogło działać. Jak Przesuniesz C1 za R2 (równolegle do R1) to ma jakąś szansę zadziałać.

pancio.ne napisał/a:

Dodatkowo RD5 jest na stałe przypięte do GND

To również nie jest możliwe, cart nie pojawił by się obszarze $A000-$BFFF, aktywny byłby tylko obszar $8000-$9FFF.

Na zdjęciu PCB widać że emiter Q1 jest bezpośrednio podpięty ścieżką do RD5, natomiast kablem od strony drugiej strony pociągnięty jest RD4 bezpośrednio do emitera Q1.

Mogłem faktycznie zamienić S4 i S5 przy wejściach bramki, sprawdzę to ;D

Cześć!

Hans 2004 napisał/a:

Czy w tych Turbo 2000... jest TAPE DOCTOR do ustawiania głowicy?

W cartach do Turbo2000(F) które widziałem, "Tape Doctor I" nie występował.  Ale są inne programy spełniające podobna funkcję (chociażby program "oscyloskop" z cartridge Atari System Turbo 2000", który udostępnił pancio.net)

Program "Tape Doctor I" widziałem jedyne w cartach dla systemu Blizzard Turbo, np. w cartridge produkcji Hurka:

https://pigwa.code32.org/aa/phoenix_1.0.jpg

Hans 2004 napisał/a:

Bo jeśli Turbo działa przez wtyczkę SIO, a przeróbka daje możliwość odczytu PWM to Tape Doctor powinien działać na każdym z nich - tzn. pokazywać "trzy linie" (najlepszy tester był chyba z kartidżu Phoenix Blizzard)

Owszem działałby (i zapewne działa) na wszystkich Turbo serii 2000 wykorzystujących do transmisji danych linie DATA_IN i bezpośredni odczyt z rejestru SKCTL, czyli np. Turbo2000F... jednak opis na ekranie jest przystosowany do czasów trwania impulsów dla systemu "Blizzard", w przypadku systemu np. Turbo2000F te czasy są znacznie dłuższe, więc siłą rzeczy na ekranie nie zobaczymy pasków w miejscach opisanych "0", "1" czy "SYNC".

Dzięki za plik BOOT, dla zainteresowanych przygotowałem wersję XEX dająca się uruchomić spod DOS-a lub dowolnego loadera plików binarnych: Tape Doctor I

https://pigwa.code32.org/atari/TapeDoctor1/TapeDoctor1.png

@pancio.net: Dzięki Wielkie za dump!

W międzyczasie narysowałem schemat na podstawie zdjęć które udostępniłeś narysowałem schemat tego carta, ale mam pewne pytania i wątpliwości, bo nie wiem czy wszystko dobrze "wypatrzyłem".

Schemat:
https://pigwa.code32.org/atari/Atari_System_Turbo2000/sch/Atari%20System%20Turbo2000.png
Schemat w wersji wektorowej: Turbo 2000 (PDF),

Teraz co do moich wątpliwości i niepewności które mam:

1) ze zdjęć nie wynika jaka jest pojemność elektrolita, mógłbyś sprawdzić?

2) również nie widzę jaka jest pojemność tego małego kondensatora ceramicznego, obstawiam coś z przedziału 56-68pF, ale warto by to zweryfikować.

3) największą wątpliwość mam jeżeli chodzi i układ resetu przerzutnika RS, czy aby na pewno dobrze widzę i jeden z rezystorów jest podpięty do ~CCTL, w normalnych warunkach powinien być podpięty do +5V, jednak wszystko wskazuje na to że w przypadku tego carta jest podpięty do ~CCTL. Teoretycznie takie podejście byłoby możliwe, i dawałoby to możliwość ponownego załączenia Cartridge po odpowiednio długim utrzymaniu linii ~CCTL w stanie 0. Piszę o tym że teoretycznie, bo nie sprawdziłem tego w praktyce czy udałoby się uzyskać przebieg który spowodował przy takie rozładowanie kondensatora aby ponownie wysterować to wejście przerzutnika (noga 1 układu 7400, aktywny stan to 0). Co prawda na drugim wejściu przerzutnika również byłoby "0", to powoduje co prawda stan "niedozwolony" ---> dwie "1" na obu wyjściach "Q" oraz "~Q", ale koniec końców to spowodowałoby ponowne włączenie cartridge.

Do kompletu wersja XEX dająca się uruchomić spod DOS-a lub dowolnego loadera plików binarnych: Atari System Turbo 2000.xex

Ale zaznaczam że nie sprawdziłem czy kod nie zawiera jakiegoś "zabezpieczenia" i czy będzie poprawnie działał uruchomiony z innego nośnika niż rzeczony cartridge. Piszę to z uwagi na fakt że w niektórych cartridge Blizzard istniało zabezpieczenie sprzętowe w postaci wymuszania stanu "0" na linii D6 magistrali danych, w chwili gdy następował dowolny odczyt z adresów $D500-$D5FF. Gdy cart nie zawierał pewnego mechanizmu sprzętowego wymuszającego takie zachowanie, loadery i oprogramowanie umieszczone na cartridge nie działały poprawnie (przykładem może być "BIG 2.0 by KNS - Blizzard Cartridge"

Być może "myk" z linią ~CCTL i układem resetu przerzutnika w przypadku tego cartridge ma tutaj jakieś "ukryte" znaczenie. Chcąc zatem używać wersji XEX lub obrazu cartridge i emulatora należy mieć ten fakt na uwadze.

EDIT: @2018.12.04: uaktualniono schematy, w/g wskazówek pancio.net

Następny kart z kolekcji to cart z naklejką "Turbo2000 COPY", który okazał się cartem zawierającym oprogramowanie dla systemu "Turbo 2T12" autorstwa Wojciecha Zabołotnego:

https://pigwa.code32.org/uicr0bee/carts/Turbo2000_WZab2T12/scr/t2000_copy_scr1.png https://pigwa.code32.org/uicr0bee/carts/Turbo2000_WZab2T12/scr/t2000_copy_scr2.png

https://pigwa.code32.org/uicr0bee/carts/Turbo2000_WZab2T12/scr/t2000_copy_scr3.png

Ktoś wykonując ten cartridge skorzystał z gotowego rozwiązania zarówno sprzętowego software-owego.

Schemat cart-a (jak i samo PCB) jest identyczny z tym który przedstawiono w poście o Turbo2000F Copy.

Software obecny w pamięci EPROM to nic innego jak software opracowany przez Wojciecha Zabłotnego. Pierwsze wzmianki o tym turbo, jednakże w wersji 2T06 można było zobaczyć w czasopiśmie IKS. System wraz z oprogramowaniem został zaprezentowany w numerach:

IKS 11/1988: oprogramowanie systemowe wraz z opisem
IKS 12/1988: errata do programu KOPIARKA
IKS 01/1989: schemat i płytka interface

Czy potem powstała nowsza wersja 2T12 sygnowana przez samego Wojciecha Zabłotnego, czy też jakiś domorosły "hacker" zabawił się w podmianę napisów nie wiem, jednak można sądzić i jakiś czas W.Zabłotny opracowywał kolejne wersje programu (w sieci można spotkać również wersję binarną sygnowaną numerem 2T09, niestety na chwilę obecną można pozostać tylko w sferze domysłów. Sam system i wspomnienia z nim związane opisał również Zenon/DIAL w magazynach Serious (K.S.O. 2T06 TURBO, Notka - TURBO 2T06).

Streszczając się nieco, po tym nieco przydługim wstępie udostępniam zatem:

1) zawartość pamięci EPROM: Turbo2000_WZab2T12

Turbo2000_WZab_2T12.bin:

MD5   : b74515156ce99bbb658ef342a91f051f
SHA256: 2821fec46fb1caf4ad75f0f2f5905987671df0d5d18c7f9d098d95a23ae7154b

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

3) schemat iak i płytka drukowana jak już wspomniałem jest  identyczna z cartridge "Turbo2000F_copy", czyli: wektor (PDF), raster color (PNG), raster grayscale (PNG). Jedyna różnica to zastosowanie tranzystora BC558B zamiast BC308B.

A sam cartridge prezentuje się tak:
https://pigwa.code32.org/uicr0bee/carts/Turbo2000_WZab2T12/photos/P1070299.JPG

PCB góra:
https://pigwa.code32.org/uicr0bee/carts/Turbo2000_WZab2T12/photos/P1070296.JPG

PCB spód:
https://pigwa.code32.org/uicr0bee/carts/Turbo2000_WZab2T12/photos/P1070298.JPG

EDITED@2025.08.13: http links fixed.

@voy: no jak możesz to poszukaj również i swojego zrzutu, będzie można porównać oba źródła, tzn. zrzut od pancio.net jak go udostępni i Twój. Będzie można oznaczyć ten dump jako zweryfikowany :)

Cześć!

robecc napisał/a:

Zamieszczam zawartość EPROMA z tego mojego carta. Dziwnie się on zachowuje na emulatorze Altirra.
...
Może ja coś popsułem w tej kości. Oby nie.

Dzięki za zrzucenie EPROM-a, przyjrzałem się temu na szybko... wygląda na to że cart ma nietypowe bankowanie którego Altirra nie obsługuje, w wolniejszej chwili rzucę okiem w kod i zobaczę co i jak dokładnie jest przełączane. Tak na szybko to podzieliłem to na dwa oddzielne pliki (po 8k) i udało się uruchomić to jako dwa niezależne cartridge, ale to było działanie trochę na ślepo, nie przyjrzałem się dokładnie bankowaniu. Jak nie kod to zdjęcia PCB które dodałeś powinny pomóc. Ale proszę o chwilę cierpliwości.

Także na 100% nic z EPROM-em nie zrobiłeś :) Wszystko jest OK! :)

A jeszcze jedno... ten Turbo System / Dadok Cartridge to jakieś czechosłowackie turbo bazujące tak jak blizzard na bezpośrednim odczycie danych poprzez rej. SKCTL POKEY-a, czyli analogicznie jak w blizzardzie, tylko format danych inny. Więc autor tego carta wiedząc że ten czechosłowacki system turbo będzie działać na sprzęcie od blizzard-a po prostu zrobił cartridge "dwa w jednym".

Pan M.Dadok jest również autorem dos-a z obsługą turbo, trochę informacji jest tutaj.

@pancio.net: Jeżeli masz czas, chęci i ochotę to jak najbardziej tak! :)

ps) i ta wojskowa wersja 7400 od CEMI (czyli UCA6400) jest przepiękna, mam chyba jeszcze kilka takich :)

Hej!

@robecc: jak najbardziej poprosimy o zrzut EPROM-a :) Nie widziałem jeszcze takiej wersji paczki/kompilacji softu dla Blizzarda.
@uicr0Bee: no to rewelacyjnie! :) Staram się zagęszczać ruchy z obecną partią.

aaaa, dobra już kojarzę to turbo i te paski :) były zrobione na grafice PMG, konkretniej chyba na pociskach. Przy odczycie jeden z nich pokazywał długość impulsów PWM zapisanych na taśmie, można było ocenić jakość nagrania, etc. Zrobię z tego pliku który jest w paczce obraz carta, żaden problem, tylko potrzebuję chwili wolnego czasu. Był chyba jeszcze do tego systemu cart z TurboDOS-em (tzn. MyDOS 4.53 + handler urządzenia "T:" obsługującego turbo, do kompletu jakiś RAM-dysk). Ale nie widzę tego nigdzie w sieci na pierwszy rzut oka.

Niestety takiego carta w swoich zbiorach nie posiadam, w obecnej partii cartów od uicr0Bee taki cart się nie znajduje.

Ale z tego czego mogę się domyślić na podstawie schematu tej przeróbki w XC12, który zrobił JER:

https://pigwa.code32.org/aa/Turbo%202001_XC12_by_jer.gif

src: Schematy ideowe TURBO do magnetofonów

Turbo2001 wygląda sprzętowo w 100% tak samo jak Turbo2000F, ale czy oprogramowanie dla Turbo2001 się czymś różniło od Turbo2000F? Niestety nie mam pojęcia bo nie mam do czego porównać, ale sprzętowa kompatybilność jest 100%. Być może format zapisu danych na taśmie jest również identyczny a zmiana nazwy z Turbo2000F na Turbo2001 była tylko "chwytem" marketingowym, aby przyciągnąć nowych klientów?

Na chwilę obecną mogę tylko zgadywać, ale prędzej czy później pewnie jakiś cart ew. jakiś samotny loader dla Turbo2001 się gdzieś pojawi i będzie można zrobić analizę porównawczą ;)

UPDATE: wygląda na to że kolega Bluki rozprawił sie z tematem Turbo2001 w tym wątku. Na pierwszy rzut oka, to z plików dostępnych w archiwum które udostępnił Bluki, wynika że Turbo2001 to nic innego jak klon Turbo2000F sygnowany i montowany przez panów z firmy TOMS. Jeden z plików wygląda na dump cartridge do Turbo2001 pewnie dało by się go przerobić ponownie na obraz dla cartridge, jeżeli istnieje taka potrzeba mogę taki plik przygotować.