Hej!

Generator "GRN-2" wylądował! Dziękuję! Przesyłka solidnie zabezpieczona na czas transportu! Nic nie miała się prawa z nią stać :) Generator działa bez problemu generuje sygnały prostokąt/sinus w zakresie 20Hz - 200KHz, przykładowy przebieg wygląda tak:

a co jest w środku? dla ciekawych zdjęcie wnętrza:

Jak widać powyżej, generator zrealizowany głównie na elementach dyskretnych, do kompletu dwa układy scalone, oczywiście klony zachodnich konstrukcji:

КР140УД1А ---> µA702; czyli typowy wzmacniacz operacyjny z epoki :)

К155ЛА1 ---> 7420; czyli podwójna w wejściowa bramka NAND:

Zadziwiające ale po takim czasie ten generator działa bez większego problemu, mała niestabilność występuje jedynie przy 200KHz na przebiegu sinus, ale o zapewne wina już wyschniętych elektrolitów. Z czasem sobie "odrestauruję" ten generator i wymienię elektrolity, na chwilę obecną wymieniłem tylko kabel sieciowy na nieco nowocześniejszy i w czarnym kolorze.

Sprzęt przyda się przy pracach z jakimiś układami m.cz. Będzie jak znalazł. mały poręczny i stabilny. W końcu jak się pracuje nad retro sprzętem to trzeba mieć też retro warsztat! nieprawdaż? :)

Dzięki Bluki! :)

@baktraaa: bardzo dziękuję za wyjaśnienie kwestii MD-DOS, teraz sprawa jest jasna! Wspominałeś również że prawdziwym przełomem były TT-DOS oraz TOS, możesz powiedzieć parę słów o tych rozwiązaniach? No i dlaczego były takie przełomowe?

Sugerowałeś też aby zrobić nowy wątek o czechosłowackich systemach turbo, mi osobiście nie przeszkadza że dyskutujemy o tym tutaj, ale jeżeli uważasz że tak będzie logiczniej i dzięki temu informacja będzie łatwiejsza do znalezienia i przeczytania to ja nie  mam nic przeciwko. Temat wydaje mi się bardzo interesujący i mógłbym o nim czytać godzinami. Oczywiście jeżeli tylko miałbyś chęci i czas opowiedzieć nam o tym wszystkim. Po ogarnięciu tego co dostałem do przejrzenia od uicro0bee chciałem się zająć analizą i przyglądaniem się tych czechosłowackich systemów Turbo. Parę razy trafiłem w kodzie różnych loaderów dla polskich systemów turbo (np. AutoTurbo) kod który łudząco był podobny do tego co mogłem zobaczyć w loaderach do czechosłowackich Turbo 2000. To by wskazywało że rozwiązania z Czechosłowacji miały duży wpływ na nasz rodzimy rynek systemów Turbo, to jest bardzo Ciekawe z punku widzenia historycznego.

@baktraaa: bardzo, ale to bardzo dziękuję za tak obszerną i dokładną odpowiedź. Nie wiem jak to robisz, ale doskonale posługujesz się językiem polskim i w dodatku rozumiesz jakie błędy w rozumowaniu popełniam przy próbie czytania tekstów w języku czeskim lub słowackim :)

Z tym "drugim standardem", powiem Ci że bezbłędnie wytłumaczyłeś ten aspekt, ja się tak zafiksowałem na systemach turbo, że zupełnie nie brałem pod uwagę tego kontekstu który naświetliłeś. Teraz wszystko stało się oczywiste.

To co opisałeś z takimi szczegółami rozwiązuje wszelakie moje wątpliwości i pozwala zrozumieć realia tamtych czasów nie tylko z perspektywy tego co się działo tutaj w Polsce ale również u was! To naprawdę niesamowite wrażenie gdy po tylu latach zastanawiania się człowiek dostaje odpowiedź na nurtujące go pytania.

W najbliższym czasie postaram się uzupełnić informację na Atariki dotyczące opisu tych systemów Turbo. Twoja pomoc jest nieoceniona! Jeszcze raz bardzo, ale to bardzo WIELKIE DZIĘKI!

ale za to z ogromną ciekawością przeczytałem cały rozdział "III Turbo Systems", to dla mnie bardzo ciekawe informacje. Fajnie że chciało Ci się to wszystko opisać.

To ja miałbym w takim razie jeszcze jedno pytanie, na taj stronie:  Jiří Pecher - Stránky o osmibitových počítačích Atari XL/XE - Turbo 2000 - úvod napisano:  "Systém Turbo 2000 pana Jiřího Richtera se ihned po svém veřejném představení prostřednictvím přílohy Zpravodaje AK Praha v roce 1987 stal v ČSSR druhým standardem." - co można chyba przetłumaczyć mniej więcej: "System Turbo 2000 pana Jiriego Richtera stał się drugim standardem w Czechosłowackiej Republice Socjalistycznej, po jego prezentacji w dodatku do biuletynu klubowego "AK Praha" w 1987 roku".

Możesz podpowiedzieć jaki system turbo był równie popularny (był pierwszym standardem" w ówczesnej Czechosłowacji?)

Z tego co udało mi się wyczytać na różnych czeskich i słowackich stronach Jiri Richter zaprezentował potem Super Turbo (to które prezentujesz na swojej stronie (https://turgen.sourceforge.io/index.php/documentation/) w pliku: Turbo2000_Upgrade.pdf <--- wydaja się być chyba jakąś odmianą super turbo od Jiri Richter-a? dobrze myślę czy się mylę?

Wnioskuję to po tym co zaprezentowane zostało tutaj:

http://blog.3b2.sk/igi/post/Dataset-Ata ... har-1.aspx
http://blog.3b2.sk/igi/post/Dataset-Ata ... har-2.aspx

Z tego co zrozumiałem potem powstało JRC czyli Jiri Richter Computing które zajmowało się produkcją i dystrybucją oprogramowania dla Turbo,

EDIT: Próbowałem znaleźć obraz tego cartridge w sieci, ale wydaje się że nie jest łatwo dostępny w zasobach internetu. I teraz mam pytanie... ponieważ firma JRC nadal istnieje, to czy brak tego obrazu w sieci jest jakoś związany z ochroną prawną tegoż oprogramowania, czy po prostu jest to trudne do zdobycia? A może nie umiem szukać?. Pełne info i zawartość EPROM dla JRC ToolBox III można obecnie znaleźć w archiwum cartów jindroush-a: JRC Toolbox III.

Tym cartem i super turbo zainteresowałem się z dwóch powodów:

1) VisiCOPY wykorzystuje grafikę PMG jako "wskaźnik postępu" podczas kopiowania, a ja sądziłem ten na ten pomysł wpadł ktoś opracowujący Turbo 2001 (odmiana turbo 2000F), ale jak zwykle wygląda na to że ktoś to wymyślił już wcześniej :)

2) Super Turbo wygląda na bardo dobrze zoptymalizowaną i przemyślaną następcę wcześniejszego Turbo2000... pomysł z wykorzystaniem istniejących elementów i dodatnie tylko prostego klucza w postaci dwóch tranzystorów jest genialny w swojej prostocie. Do tej pory sądziłem że to twórcy Turbo 2000F wpadli na ten pomysł, jednak widzę że J.Richter był pierwszy, a Turbo2000F to jeszcze bardziej uproszczona wersja "Super Turbo" od J.R.

Edited on 2025.08.18: Updated HTTP links to HTTPS to avoid mixed content issues.

Hej!

Byłbym zainteresowany!

Dzięki! Postaram się to sprawdzić dziś wieczorem i dam oczywiście znak jak to sprawdza się z moim magnetofonem KSO + Turbo 2000F.

Tak, tak... widziałem jak przekładałem sprzęt z paczki do pojemnika "to do" ;-) jeżeli nie będzie żadnych niespodzianek to niebawem pewnie pojawią się nowe wpisy w tym wątku ;-)

Hej!

Długo mnie nie było, ale cóż... życie. Wracam do tematu detekcji typu turbo w przypadku loader-a speedy 2700 wersji którą zaprezentował baktraaa, wszystko stało się jasne... w sumie to nie wiem czemu tego wcześniej nie zauważyłem ;-/ Aby dokładnie wyjaśnić o co chodzi muszę zaprezentować zachowanie realnego hardware i opisać to co będzie widać. Wybaczcie marną jakość filmu, ale kręciłem to "z ręki" próbując drugą ręką pisać na klawiaturze i ogarniać jednocześnie sprzęt, wyszło jak wyszło... ale jakbym się z tym "pieścił" to zajęło by mi to kolejne tygodnie :P także wybaczcie, jest jak jest...

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

Co właściwie widać na filmie? Do Atari podłączony jest magnetofon XCA12 z K.S.O. Turbo 2000 oraz z Turbo 2000F (ale przełącznik od Turbo 2000F jest w stanie "normal"). Zatem loader Speedy 2700 powinien poprawnie wykrywać K.S.O. 2000.

Wykrywanie jest dokonywane przez monitorowanie stanu bitu #7 w porta A, a więc wtyczka od interface turbo jest podpięta zgodnie ze sztuką pod drugi port JOY-a. Na filmie klepię kawałek kodu który ma na celu odczytanie PORTA, przesunięcie jego bitów tak aby zmiany w górnej połowie bitów PORTA było odwzorowane jako zmiany kolorów ramki.

Należy dodać że domyślnym stanem wszystkich bitów PORTA w chwili gdy nic do portów nie jest podłączone (lub gdy joystick nie jest wychylony w żadnym kierunku) jest stan "1". Natomiast po podpięciu kabla od interface do portu joysticka #2, jak pisałem przed chwilą bit #7 reprezentuje aktualny stan na wyjściu dyskryminatora danych tegoż interface, co znaczy tylko tyle że to co interface analizując sygnał na jego wejściu (z taśmy) decyduje czy to co obserwuje na wejściu będzie "1" lub "0" logicznym? A co się dzieje kiedy nie ma żadnego użytecznego sygnału na wejściu interface?

To właśnie pokazuje początek filmu... jak się okazuje w większości czasu na wyjściu interface będzie panowało logiczne "0", i ten fakt wykorzystuje *AJEK aby zdecydować czy ma do czynienia z interface K.S.O. Turbo 2000... tzn. dokonuje odczytu PORTA a i sprawdza czy tam znajduje się "0", jeżeli tak to zakłada że interface K.S.O. musi być podłączony (bo przecież w normalnych warunkach powinno tam być zawsze "1").

Ale jak pokazuje filmik, taka metoda detekcji jest tylko pozornie dobra, bo zdarzyło mi się że loader Speedy 2700 trafił akurat na "1" i przełączył się na Turbo 2000F (które miałem wyłączone) zatem z odczytu nagrania wyszło "wielkie nic" :) Przez większość czasu to działa (jak ktoś chce można liczyć prawdopodobieństwo)... Ale jak widać na filmie nawet interface z wyłączonym silnikiem potrafi wystawiać "1" logiczne mimo braku obecności sygnału z kasety na wejściu.

Od 0:30 - 0:42 widać właśnie ten stan, potem na filmie uruchamiam silnik magnetofonu ($D302=$34) i pokazuje zachowanie gdy silnik pracuje (kasety w kieszeni brak, ale na początku PLAY jest wyłączony [0:56], a potem zostaje wciśnięty [1:02]).

Jak więc widać metoda detekcji u *AJKA jest również niezbyt pewna i daje błędne rezultaty. *AJEK włącza niby od razu silnik, ale na szczęście detekcji dokonuje bardzo szybko po tym fakcie i silnik nie zdąży ruszyć i cały magnetofon przez chwile znajduje się jeszcze w stanie nazwijmy to "IDLE", to zwiększa prawdopodobieństwo że u *AJKA są szanse aby loader poprawnie pracował z K.S.O. 2000.

Pytanie czemu to nie działa w loaderze od Baktraaa? Nie wiem jak na to wcześniej patrzyłem, ale jest to tak oczywiste że sam się dziwię że tego wcześniej nie dojrzałem. Sądzę że Baktraaa disassemblował kod loader już po tym gdy ten dokonał detekcji systemu turbo (nie wykrył KSO) i w kod loadera procedura detekcji wpisała wartości które odpowiadają pracy loadera z Turbo 2000F/AST, etc.

Domyślnym stanem (startowym) loadera jest stan w którym ma on wpisane w procedury odczytu wartości odpowiadające odczytowi danych z K.S.O. 2000. Potem następuje detekcja i ew. korekta loadera tak aby czytał z Turbo 2000F, w przypadku disassemblacji kodu po detekcji efekt będzie taki że loader już nigdy nie będzie miał możliwości przełączenia się na K.S.O. 2000, bo śladu po tych instrukcjach odczytujących z PORTA bit #7 już nie ma. Pojawić się nie mogą, bo procedura detekcji tylko przełącza na Turbo 2000F, więc przełączanie z Turbo 2000F na Turbo 2000F niewiele zmienia ;-)

procedury odczytu przed detekcją w oryginale wyglądają tak:

W tych procedurach powyżej widać sekwencje:

LDA #$80
BIT $D300

tymczasem u Ciebie baktraaa jest na starcie:

LDA #$10
BIT SKSTAT ; $D20F

zatem procedura detekcji przełączenia znajdująca się od linii 296, czyli:

            lda PORTA                     ;Check signal at joystick port
            bpl L085E                     ;If no signal, then skip
            
            lda #$0F                      ;Modify the decoding routine so
            sta L0708                     ;it reads from the joystick port
            sta L0715
            sta L072E
            sta L0739
            lda #$D2
            sta L0709
            sta L0716
            sta L072F
            sta L073A
            lda #$10
            sta L0706
            sta L072C

nie ma prawa działać.

Można to poprawić w procedurach odczytu na odwołania do KSO, albo zmienić procedurę detekcji tak aby wykonywała się zawsze gdy zostanie wykryte KSO, czyli:

            lda PORTA                     ;Check signal at joystick port
            bmi L085E                     ;If no signal, then skip
            
            lda #$00                      ;Modify the decoding routine so
            sta L0708                     ;it reads from the joystick port
            sta L0715
            sta L072E
            sta L0739
            lda #$D3
            sta L0709
            sta L0716
            sta L072F
            sta L073A
            lda #$80
            sta L0706
            sta L072C

jednak tak jak pisałem przydałoby się sprawdzić więcej niż raz czy w PORTA bit #7 nie zmienia stanu na "0", lub że przez jakiś okres czasu bit #7 w PORTA ma zawsze stan "1", można to zrobić jakoś tak:

; wait for scanline #0
    
    lda    $d40b
    bne    *-3
    
dt_loop    lda    PORTA
    bmi    dt_wait
    
; KSO detected ...    
    
    lda    #$00
    sta    ...
    sta    ...

    lda    #$d3
    sta    ...
    sta    ...

    lda    #$80
    sta    ...
    sta    ...
    
    jmp    dt_end
    
dt_wait    lda    $d40b
    bpl    dt_loop
    
dt_end

... lub oczywiście w dowolny inny sposób który Ci przyjdzie do głowy i który będziesz uważał za słuszny.

Gdybym coś za ostro zamotał i napisał zbyt niejasno to oczywiście nie wahaj się pytać.

ps) przepraszam że tyle czasu to trwało, ale naprawdę nie miałem się do tego kiedy zabrać ;/

Edited on 2025.08.18: Updated HTTP links to HTTPS to avoid mixed content issues.

Sprawdzę na moim XC12 z KSO 2000, dam znać za parę dni. Zaraz po tym jak zrobiłeś wsparcie dla Speedy2700, sprawdzałem na emulatorze:

http://www.arus.net.pl/FUJI/a8cas-util/ ... lator.html

i to działało bez problemu (zarówno w trybie KSO jak i Turbo /manual switch/) i to działa bez problemu.

no to zacznę licytację TI 99/4a... 400zł na start.

Hej!

Ja również dziękuję, cieszę się że komuś to się jeszcze przydała :) Paczka do PIN-a chyba też dotarła, więc sądzę że można zamykać temat.

@pilat23: podzielisz się z PIN-em? 2 szt. dla Ciebie (byłeś o 6 sek. szybszy) a jedna dla PIN-a?