Hej!

Powoli zbliżam się do końca prac nad interfejsem. Wszystko wskazuje na to że schemat jest poprawny, kolega darpajdp zgłosił parę uwag i po poprawkach opublikuję całość. Ale wcześniej jeszcze chciałem przeprowadzić parę testów ładowania różnych programów i ich konwersj do długich bloków. Interesowała mnie też stabilność działania interfejsu oraz pewność wczytywania danych zarówno standardowych jak i tych w formacie 2600/DB. Powiem wam że nie udało mi się trafić na żaden błąd podczas wczytywania danych z użyciem interfejsu firmy SZOK. Nawet "standard" wczytywał się pewnie i poprawnie, co mnie dziwi bo powinienem przecież trafić na błąd który czai się w OS-ROM komputera na użytkowników komputera.

Zapewne już to nikogo nie interesuje, ale z kronikarskiego obowiązku przeprowadziłem sobie te wszystkie testy wczytywania na realnym sprzęcie. Do tego celu użyłem specjalnie przygotowanej przeze mnie gry DRACONUS, jej specjalne przygotowanie polegało po pierwsze na dołączeniu do niej obrazka podczas wczytywania, ale uczyniłem to w taki sposób aby było widać ten wczytujący się po kawałku obrazek w trakcie ładowania danych... a po drugie aby całość gry zmieściła się w buforze programu TRANS FILE DB, musiałem spakować grę... użyłem w tym celu Super Packera od TeBe i wybrałem kompresję za pomocą Exomizera. Gra zajmowała w oryginale obszar $600-$BBFF, wiec ciężko było aby to wraz z obrazkiem (który ma prawie 8 kB) zmieściło się z buforze "Trans File DB", aby nie przedłużać już więcej, to w tym poście publikuję filmy prezentujące wczytanie w formacie DB z prędkościami 2600, 1300, 800 bitów na sekundę oraz standardowe wczytywanie gry z prędkością 600 bps. W przypadku gry zapisanej w standardzie użyłem swojego 1-blokowego loadera plików binarnych Atari DOS (o tym więcej niebawem, bo powstał on niby dawno, dawno temu, ale skoro była okazja oby go wykorzystać to czemu nie), przed linkami do filmów na YT (których i tak nie będzie pewnie oglądał, bo nie nie ma właściwie czego oglądać ;P)

Zamieszczę tylko krótkie zestawienie:

Rozmiar wczytywanego pliku (w formacie binarnym Atari DOS) to: 35064 bajty.

Czas wczytywania poszczególnych wersji:

• Draconus (T2600, DB, 2600 bps): 2 min 56 sek

• Draconus (T2600, DB, 1300 bps): 5 min 15 sek

• Draconus (T2600, DB, 800 bps): 8 min 24 sek

• Draconus (T2600, DB, 600 bps): 11 min 04 sek

• Draconus (Normal, FSK, 600 bps): 11 min 44 sek

I teraz linki do video na YT, przedstawiające proces ładowania. I tak jak poprzednio proszę ukryć zwierzęta domowe, a domowników wrażliwych na te przerażające dźwięki proszę odizolować, albo założyć na uszy słuchawki :) I tak samo jak poprzednio w kanale lewym leci dźwięk z Atari, w kanale prawym to co słyszy interfejs.

Dziś już nie mam czasu i siły ale jutro wieczorem wrzucę pliki (wav, cas, xex) do kolejnego postu w tym wątku. Dla ciekawych jak wygląda loader szybki link do repozytorium na GitHub zawierający kod źródłowy "Code3 Tape Loader. Parę słów więcej o tym loaderze napiszę w innym wątku na forum (w dziale programowanie).

DRACONUS, format DB ładowanie z prędkością 2600 bps:
http://www.youtube.com/watch?v=pfKimlOnDvw

DRACONUS, format DB ładowanie z prędkością 1300 bps:
http://www.youtube.com/watch?v=k3x9zTYjD-0

DRACONUS, format DB ładowanie z prędkością 800 bps:
http://www.youtube.com/watch?v=55yr34IKlUA

DRACONUS, format standardowy, ładowanie z prędkością 600 bps:
http://www.youtube.com/watch?v=EQPUdTIRjbA

Hej!

To że dźwięki systemu T2600 są tak mało "komfortowe" dla uszu może tłumaczyć jeden obrazek:

Ten obrazek pokazuje widmo sygnału zapisanego w systemie T2600 (standardowe rekordy po 128 bajtów, prędkość 2600 bps) ... z tego obrazka można wywnioskować iż widmo takiego sygnału jest bardzo bogate we wszelakie harmoniczne... co może generować bardzo nieprzyjemne interferencje w widmie dźwięku... to by też tłumaczyło konieczność stosowania filtra pasmowo-przepustowego na wejściu interfejsu.

Na przykładzie WARHAWK widać też ile "pary szło w gwizdek", na generowanie przerw między rekordami... nie przyglądałem się temu jeszcze dokładnie, ale wygląda na to że w przypadku "Turbo 2600" sekwencje kalibracyjne, lecą bezpośrednio w ciągłym strumieniu danych i procedury I/O systemu T2600 dokonują automatycznej kalibracji w chwili gdy ową sekwencję napotkają.

Zaczynam się zastanawiać czy ktoś kto projektował ten system nie miał doświadczenia zawodowego z jakimiś większymi systemami taśmowymi czy może jakimiś dużymi systemami dyskowymi.

W przypadku T2000 najkrótrzy genrowany impuls kodujący "zero" logiczne miał 0.25ms a więc około 4KHz, więc to była częstotliwość nieco mniej drażniąca niż 5.1KHz wybrane dla kodowania "1" przy modulacji FSK.

A co do pisku i że teraz trudno tego słuchać... należy pamiętać że kiedyś pasmo wzmacniacza w jakimś telewizorze i monitorze nie było powalające, więc 3900 i 5100Hz na wbudowanym w TV/Monitor głośniku nie było aż tak dokuczliwe jak dziś, gdy słuchamy to na sprzęcie który potrafi bez problemu odtworzyć dość wysokie częstotliwości... paradoksalnie dzisiejsze TV czy Monitory mają problem raczej z niskimi częstotliwościami (z racji wymiarów skrzynek w których je obecnie się zamyka).

Sprawdziłem to nawet doświadczalnie na sobie... słuchając tego na głośniku wbudowanym w monitor TWM-315 daje się to wytrzymać... jednak daleko temu do "muzyki" jaką jest wczytywanie z prędkością 600 bps ;-)

Trochę mi to zajęło, bo graber nie chciał współpracować, a potem przy zestawieniu całości tworzyły mi się jakieś "pętle masy" pomiędzy całym sprzętem i miałem niezły "brum" w audio, zresztą nie jest wcale tak rewelacyjnie jeżeli chodzi o jakość dźwięku, ale lepiej tak niż wcale...

Zatem za zainteresowanych przykład wczytania gry DROPZONE przy użyciu systemu Turbo 2600. Grę zapisano w formacie długich bloków z prędkością 2600 bps. Wczytywano ją za pomocą interfejsu udostępnionego przez Thomy-ego. W lewym kanale słychać dźwięk z Atari, w prawym to co "słyszy" interfejs.

Czas wczytania gry w tym formacie to 2 minuty i 53 sekundy:
https://www.youtube.com/watch?v=hnNdNUMXgjk

... dodam tylko że czas wczytywania tej gry w standardowym formacie to 11 minut 51 sekund.

@Thomy: Dzięki! Teraz jasne. Będę testował.

@Sikor: no prawie sprytne... po pierwsze DOS musi nie korzystać z pamięci pod ROM,  po drugie w ten sposób tylko zapisać można w standardowym formacie (rekordy 128 bajtów) tyle że prędkość może wynosić 2600 bps. O ile dobrze zrozumiałem być może da się odczytać format DB, ale tego nie jestem pewien. Sprawdzę, bo jeżeli by się dało odczytać format DB to byłaby szansa na konwersję plików z formatu DB do normalnej postaci.

Fakt! Zobaczyłem µA741 i zafiksowałem się na 12V, ale faktycznie kolektor BC107 jest podpięty do VCC, więc to musi być +5V.

Myślę że to z tego względu że część ludzi miała interfejsy oparte na klasycznej wersji tego co jest w trzewiach magnetofonów Atari, tzn. filtry pasmowe+komparator i one często i gęsto więcej niż 900 bodów nie "łykały". Więc emisje w Radiokomputerze ograniczyli do maks. 800 bodów w przypadku formatu długich bloków systemu 2600, a większość pozostałego softu leciała w standardowym 600 bodów. Wyjątkiem były jakieś programy Darka Rogozińskiego / Iron Soft które były nadawane czasami trochę szybciej (zapewne sam ich autor dostarczał je w takiej formie).

Jak najbardziej tak! Chciałem zebrać wszystko w jednym wpisie wraz z nagranymi materiałami, dlatego teraz jest taka dłuższa cisza... bo przygotowałem sobie kilka plików do konwersji na format T2600 i po wykonaniu kilku ładnych eksperymentów i spędzenia jednego wieczoru na zabawie z tym systemem, powiem tylko tyle że jestem zaskoczony jego efektywnością i niezawodnością. Szkoda że ten system nie zyskał na popularności w swoim  czasie, bo różnica w pewności wczytywania (nawet z użyciem prędkości 2600) jest kolosalna w porównaniu ze standardowym rozwiązaniem Atari. Skracając nieco moją wypowiedź... nie udało mi się przez kilka godzin zobaczyć żadnego błędu wczytywania... zarówno używając zapisu ze standardowymi 128-bajtowym rekordami nagranymi z prędkością 2600, jak i z formatem DB (długie bloki).

Tzn. mogę się domyślać się dlaczego tak się stało, ale to tylko moje czyste spekulacje. Niestandardowy format, w dodatku wychodzi na to że zamknięty i nie udokumentowany przez firmę SZOK, przynajmniej nie publicznie... Nie wiem czy owym czasie była do tego systemu jakaś bardziej rozbudowana dokumentacja czy opis, bo to co dołączono do programów jest raczej skromne i mało wyjaśniające niektóre kwestie, Nawet w instrukcji/gwarancji którą tutaj zaprezentował Thomy nie było wiele słów wyjaśnienia dotyczących działania systemu i obsługi programów do niego dołączonych.

Do tego dochodziła kwestia tego, że chyba niemożliwa była konwersja z formatu DB do pierwotnej postaci. A przynajmniej nie znam metody ani programu który by umożliwiał taką operację. Co prawda jest jakiś program opisany "... do współpracy ze stacją dysków", ale nie udało mi się go uruchomić tzn. nie przyłożyłem się zbytnio, ale pierwsze próby jego uruchomienia kończyły się wyjściem do BASIC-a i SELFTEST-u.

Do kompletu zapewne dochodził fakt że system Turbo 2600 lokował się pod OS-ROM i gdy jakakolwiek gra czy program próbowała wykorzystać ten obszar lub w jakikolwiek sposób manipulowała rejestrem PORTB to pojawiały się problemy.

Gdyby powstało nieco więcej narzędzi, albo format byłby bardziej udokumentowany i otwarty być może ów system przyjąłby się w większym stopniu.

W przypadku systemu Turbo 2600 użycie modulacji FSK i wykorzystanie mechanizmów sprzętowych POKEY-a powoduje że ekran podczas wczytywania z prędkością 2600 może pozostać włączony. Dodatkowo w systemie T2600 ciekawe jest to że transmisja danych leci sobie "na przerwaniach IRQ", a tzw. ciągu głównym CPU można sobie robić w czasie transmisji różne inne rzeczy... przykładem użycia tej techniki była gra FEUD, transmitowana w Radiokomputerze,  podczas wczytywania której była odtwarzana muzyka i można było pograć sobie w grę "odwracanka".

Kończąc ten nieco już przydługi wpis przygotuję parę materiałów video prezentujących jak się wczytują gry z użyciem różnych sposobów zapisu i interface którzy przekazał mi Thomy do testów i analizy i wrzucę wyniki do tego wątku. Po obejrzeniu tych materiałów "z dźwiękiem", dojdziecie pewnie do takich samych wniosków jak ja... dźwięk wczytywania danych FSK przy prędkości 2600 jest na tyle okropny że to pewnie dlatego ten system nie zyskał na popularności* ... przy nim standardowe bloki wczytywane z prędkością 600 bodów, to muzyka dla każdych atarowskich uszu ;-)

*) to oczywiście żart ;-)

Hej!

Dzięki! Mi się udało jeszcze znaleźć skan z jakiegoś polskiego katalogu tranzystorów (źródło). Na wszelki wypadek (gdyby źródło zniknęło) to dla zainteresowanych załączam skan/PDF-a do tego postu.

A pytałem o notę katalogową (datasheet) bo ciekawy byłem oryginalnej dokumentacji do tegoż tranzystora (dowolnego producenta który to produkował, a było ich z tego co widzę kilku), ale wygląda na to że w sieci nie występuje jako popularny byt, być może jest to w jakimś większym katalogu tranzystorów i nie odnajduje się tak łatwo.

Hej!

Oczywiście masz rację, mój błąd. Poprawiłem. Dzięki za czujność!

A co do budowy interface, to faktycznie jest on mocno rozbudowany. Do tego wszystkiego jeszcze dochodzi płytka przedwzmacniacza i filtrów aktywnych. Wczorajszy wieczorny "szybki rzut okiem" sugeruje dwu-sekcyjny komplet filtrów górno+dolno przepustowych.

A widzisz, nie wiedziałem że odpowiednikiem BC206B był BC159B. Na płytce przedwzmacniacza i filtrów siedzą właśnie dwa takie BC206B, ale już w pozostałych miejscach siedzą po prostu BC159B. Zastanawiałem się dlaczego akurat w przedwzmacniaczu/filtrach BC206B, ale teraz mi już wyjaśniłeś że nasze rodzime BC159B mogły nie spełniać kryteriów konstruktorów z firmy SZOK. Do tej pory zakładałem że po prostu płytki przedwzmacniacza/filtrów były montowane w innym czasie, lub po prostu takie tranzystory były pod ręką. Dzięki za wskazówki i wyjaśnienie sprawy!

raport o postępie prac...

Udało się praktycznie rozrysować całą płytkę demodulatora FSK, dla zainteresowanych załączam wstępną wersję schematu tej płytki, jeszcze bez stopnia wejściowego, którego nie przerysowałem do KiCAD, niemniej jednak ten demodulator:

^^^ otwórz w "nowej karcie" aby uzyskać większą rozdzielczość obrazka ^^^

Jest dość ciekawą koncepcją, składa się z tak jak w przypadku interfejsu zaprezentowanego przez markka, z podwajacza częstotliwości, ten jednak działa na nieco innej zasadzie, można uznać że pracuje w domenie "prawie" cyfrowej, mówię prawie ponieważ jeden z sygnałów tworzonych przez przerzutnik astabilny 74121 (pracujący jako element dyskryminatora częstotliwości) został wykorzystany jako układ "formujący impulsy", dla poprawienia stabilności pracy podwajacza częstotliwości.

Natomiast cały dekoder FSK działa na zasadzie dyskryminatora częstotliwości stworzonego właśnie z dwóch przerzutników astabilnych 74121 oraz jednego przerzutnika typu D (1/2 układu 7474).

Muszę przyznać że taką koncepcję "podwajacza" częstotliwości widzę po raz pierwszy na oczy, natomiast konstrukcja dyskryminatora jak sądzę była powszechnie znana w tamtych czasach (mówimy o roku 1988).

Zaprezentowany powyżej układ "zasymulowałem" na szybko i wygląda na to że działa bez problemu w symulacji, więc jest szans że nie pogubiłem się w tym "zamiąchu" ścieżek, oczywiście będę jeszcze to weryfikował, przy dalszych pracach nad analizą interfejsu.

A dla Markka należą się kolejne wyrazy uznania, za to że jego interface realizuje tą samą funkcjonalność w o wiele mniej skomplikowany sposób. Koncepcja z podwajaczem jak widać była w 100% trafiona! Marekk zrealizował to jednak w "domenie analogowej", a w przypadku konstruktora interfejsu z firmy SZOK mamy realizację podwajania w domenie cyfrowej za pomocą DPLL-a zrealizowanego "na piechotę" :)