451

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

Panowie,

Kolega ma w magnetofonie Wrocławskie Turbo 2000/3000. Jest to klon 1:1 Czeskiego Turbo 2000, które też opisałem w Atariki jakiś czas temu: Czeskie Turbo 2000

@sikor... napisałeś że czeskie nie jest opisane, ale jest, tylko system odnośników i miejsc w Atariki do różnych "systemów turbo" jest tak zamieszany że nie ogarniam aby we wszystkich miejscach to linkować, np. czeskie turbo widać tutaj: Systemy Turbo.

Problem z wczytaniem jest spowodowany tym że kolega ma kasety zapisane w standardzie Turbo 2000F/2001/KSO2000 i soft który dostał do tych systemów na carcie po prostu nie włącza tego interfejsu i magnetofon pracuje cały czas w normalu. Oczywiście za pomocą interfejsu który ma w magnetofonie można wczytywać również i takie kasety, ale to wymagałoby drobnej modyfikacji loader-a/softu dla Turbo 2000F/2001 aby ten aktywował interface Turbo w magnetofonie zmieniając stan linii COMMAND portu SIO na aktywny przed rozpoczęciem wczytywania danych w systemie turbo. Można dołożyć również przełącznik który będzie przełączał tryb pracy magnetofonu n Turbo manualnie, wtedy modyfikacja softu nie byłaby konieczna. W jednej pozycji przełącznika Turbo byłoby cały czas włączone, a drugiej pracą normal/turbo sterowałaby linia COMMAND tak jak ma miejsce to w chwili obecnej.

Podrzuciłem koledze plik do testów nagrany za pomocą "Special Copy 1.5" od Tomasza Rolewskiego który jest przeznaczony właśnie dla tego interfejsu. Dodaję go również w załączniku aby każdy posiadający to turbo mógł sobie przetestować jego działanie u siebie (plik WAV spakowany 7zip-em).

A poniżej podgląd z emu jak wygląda ten proces wczytywania:
https://www.youtube.com/watch?v=oKSzzLaKJho

452

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

pod atari800 też da się uruchomić ten ROM. Zamiast SELF-TEST jest klasyczny "MEMOPAD", kolory tła, ramki i liter są zamienione, z Atari 8-bit FAQ wynika:

Expander / The Expanders, by R.G.T. for Synergy Concepts, (c)1986
- For computers with up to 512KiB of Port B banked memory (576KiB total system RAM)
- XL OS with added Executive Program for managing up to four RAM drives
- All RAM drives contain 707 sectors.  RAM drive configurations supported:
   - One RAM drive of 90KiB (emulated SS/SD floppy disk drive)
   - Two RAM drives of 90KiB (emulated SS/SD floppy disk drives)
   - Three RAM drives of 90KiB (emulated SS/SD floppy disk drives)
   - Four RAM drives of 90KiB (emulated SS/SD floppy disk drives)
   - One RAM drive of 180KiB (emulated SS/DD floppy disk drive)
   - Two RAM drives of 180KiB (emulated SS/DD floppy disk drives)
- Renumber drives and boot from any drive
- Built-in mini-DOS

Wciśnięcie RESET+SELECT odpala takie menu:

http://seban.pigwa.net/aa/the_exppanders_ROM_by_RGT.png

... i albo słabo szukam, albo nie wiem co... bo niewiele o tym produkcie w sieci znaleźć mogę.

453

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

Hej!

Zgodnie z obietnicą w załączniku do pobrania wszystkie pliki na których przeprowadzałem eksperymenty z interfejsem Turbo 2600: Draconus - extended version

W archiwum pliki CAS, HEX, WAV. Oraz wersja FILE/XEX (z obrazkiem podczas ładowania) którą przygotowałem na potrzeby testów. Jest także wersja cas i hex w "standardzie" o którą prosiłem, poprzedzona loaderem jedno-blokowym o którym pisałem parę postów wyżej.

454

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

Hej!

xtrem007 napisał/a:

@seban: Czy możesz udostępnić wersję kasetową Draconus (Normal, FSK, 600 bps) w pliku cas lub wav?

Jasne! Tak jak pisałem wcześniej... udostępnię wszystkie pliki jak tylko dotrę do komputera na którym się obecnie znajdują (zapewne będzie to dziś wieczorem). Ta wersja Draconusa powstała właśnie na potrzeby testów które tutaj zaprezentowałem. Zrobiłem ją wykorzystując to co "leżało" na Atarimania (Draconus). Obrazek wyciąłem z wersji dyskietkowej, a resztę z wersji kasetowej, pozbywając się oryginalnego boot-loadera.

455

(5 odpowiedzi, napisanych Programowanie - 8 bit)

Hej!

xxl napisał/a:

dwa slowa, jesli szukasz miejsca na ZP to to wydaje sie najodpowiedniejsze dla tego typu programu:

Disk file manager system (FMS) page zero registers (seven bytes).

Dzięki za info, sprawdzę czy po użyciu tych lokacji zmieszczę loader w jednym rekordzie w pełnej wersji.

xxl napisał/a:

sprawa dwa... nie warto ograniczac sie do "128 bajtow" ze niby 1 rekord... wspanialy OS wymusza jeden rekord wiecej

No ale ta moja wersja 1-rekordowa uruchamia się dokładnie po wczytaniu jednego rekordu i nie wymaga rekordu EOF. Jak pisałem wcześniej ten pomysł podrzucił Pecuś opisując go dokładniej w tym poście: jedno blokowy BOOT, a zaczęło się od tego pytania.

Wracając to głównego wątków u mojej jedno-blokowej wersji loadera... masz dokładnie jeden rekord i potem już bez długiej przerwy IRG mogą lecieć następne rekordy zawierające dane pliku, widać to na tym przykładzie:

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

xxl napisał/a:

... ktory i tak musi byc co nie znacz :DDD ze ten rekord ma byc pusty :DDD prosta sztuczka z kopiowaniem zawartosci tego niby pustego rekordu i nagle zyskujesz miejsce na kod ;-)

No ale tak właśnie robi wersja 2-rekordowa, tzn. ładuje dwa rekordy (bez rekordu typu EOF) i potem kopiuje pozostałe dane z bufora magnetofonu ($400-$47F) w docelowe miejsce ($780-$7FF) po czym już bez przerwy IRG mogą lecieć dane wczytywanego pliku.

Zatem jak widać podane wielkości loderów podałem bez pustych rekordów EOF które w obu przypadkach nie są wymagane, a wręcz nie powinno ich być.

qbahusak napisał/a:

Że też nikt? W tamtych czasach nie wrzucił loadera na stos, tam się marnuje jakieś 240-250 bajtów przy prostych programach (a takim jest loader). Wtedy bufor robimy na stronie zerowej od 0x80 i wszystko się wczyta.

Powiem tak... w czasach kiedy powstawał ten loader, to wśród ludzi krążyły różne i tak dziwaczne wersje plików i gier że lokowały się gdzie popadanie, również na stosie (np. pliki wykonywalne potraktowane np. "Zagęszczaczem" od Darka Rogoźińskiego / IRON SOFT umieszczały swoje procedurę czyszczenia pamięci właśnie na stosie) ... do kompletów część programów podczas ładowania wykonywała jakieś karkołomne operacje w pamięci, przepisując się tu i ówdzie i korzystając w tym celu z "losowo" wybranych komórek na stronie zerowej. To wymuszało na człowieku który pisał loader aby nie wykorzystywał on żadnych lokacji na stronie zero, bo spora część programów podczas ładowania mogła pozmieniać zawartość różnych komórek na stronie zero.

Była cała masa plików typu "file" które łamały dobre zasady "kodowania" i lokowały się w różnych dziwnych miejscach, stąd właśnie chęć uniknięcia tych wszystkich różnych dziwnych obszarów... sam święty nie byłem i jak chciałem sobie zrobić wersję file jakiegoś dużego programu to upychałem swoje wstawki gdzie się tylko dało (np. w buforze drukarki $3C0-$3E7)

456

(5 odpowiedzi, napisanych Programowanie - 8 bit)

Hej!

Dawno, dawno temu... w czasach kiedy jeszcze magnetofon jako pamięć masowa nie był niczym dziwnym ... a różnego rodzaju gry i programy w binarnym formacie Atari DOS były zapisywane na taśmę i poprzedzone tzw. loaderem "!", dziwiło mnie zawsze czemu ten loader jest tak długi... nigdy jednak nie zgłębiałem jego tajemnic i nie analizowałem kodu tegoż loadera... jednak przyszedł czas że postanowiłem napisać własny tego typu loader... wtedy udało mi się go zmieścić w dwóch standardowych rekordach i można było sobie ów mój loader umieścić zamiast "!" przed programem w formacie "binary DOS file", potem powstał do kompletu "Code3 Tape Copy", ale ja nie o tym... przy okazji wątku o interfejsie Turbo 2600 firmy SZOK ze Świebodzina i testów które tam wykonywałem odkopałem ów mój loader wśród jakichś archaicznych źródeł... oryginał loader powstał gdzieś na początku lat '90 gdy jeszcze istniało Code3.

Przy okazji "walki" z testami wczytywania z pomocą interfejsu dla systemu Turbo 2600, przypomniało mi się że na tutejszym forum Pecuś zaprezentował swój loader dla systemu AST, który to miał pre-loader w standardzie który startował po wczytaniu jednego rekordu, opisał nawet metodę i trik jaki należy zastosować aby coś takiego można było stworzyć tego typu plik BOOT (taki który wystartuje po wczytaniu tylko jednego rekordu danych)... przypomniało mi się to i postanowiłem sprawdzić czy nie da się zmieścić całego loadera plików typu "file" w jednym rekordzie danych (a więc 128 bajtów + nagłówek typu BOOT). No i udało się... wziąłem kod swojego starego loadera i obciąłem go tak aby mieścił się w jednym rekordzie danych i startował ładowanie pliku typu file właśnie po wczytaniu tego jedynego rekordu danych.

Nie wiem czy to w dzisiejszych czasach komuś się jeszcze przyda, ale skoro już wygrzebałem to z przeszłości i dopisałem wersję 1- blokową, to postanowiłem to upublicznić, zatem gdyby ktoś był zainteresowany to zapraszam do zajrzenia do repozytorium zawierającego kod źródłowy tego loadera na github: CODE3 Tape Loader.

W repozytorium znajdują się dwa pliki:

  • c3_loader_pg7.xsm

  • c3_loader_1blk.xsm

Plik "c3_loader_pg7.xsm" zawiera oryginał loadera napisany latach '90, lokuje się on w przestrzeni $700-$7FF i może wczytywać pliki binarne które mieszczę się w adresach: $0480-$06FF, $0800-$FFFF. Loader wykonuje skoki do segmentów INIT (zatrzymując silnik magnetofonu) oraz uruchamia program skacząc pod adres wskazany przez segment RUN. Jeżeli program nie zawiera segmentu RUN, loader uruchomi program od pierwszego segmentu który jest obecny w pliku.

Plik "c3_loader_1blk.xsm"m zawiera skrócony loader który zajmuje teraz 128 bajtów i ładuje się w obszar $36B-$3EA, zatem wczytywany program może zajmować obszar $0480-$BFFF.

Obie wersje loaderów wykorzystują obszar $400-$47F jako bufor na rekord odczytany z magnetofonu. Oba loadery ze względu na optymalizację rozmiaru wykonują skoki bezpośrednio do OS-ROM i oczekują że mają do dyspozycji Atari XL/XE OS-ROM v.2.

Drugi loader (1-blokowy) nie będzie potrafił uruchomić gry/programu która nie zawiera adresu uruchomienia wskazanego przez segment RUN ($2E0-$2E1).

Oczywiście wczytywane gdy i programy mogą również korzystać z przestrzeni pod OS-ROM, jeżeli same przekopiują tam dane podczas wczytywania. Żaden z loaderów nie wykorzystuje żadnej lokalizacji na stronie zerowej. Zapewne dałoby się jeszcze skrócić loader 1-blokowy tak aby zmieścił się w jednym rekordzie i mógł programy nie zawierające segmentu RUN, gdyby wykorzystać jakieś komórki na stronie zerowej.

Przykład ładowania gry DRACONUS z wykorzystaniem 1-blokowego loadera można obejrzeć w wątku o "Turbo 2600".

Zdaję sobie sprawę że w dzisiejszych czasach taki loader zapewne nikomu przy zdrowych zmysłach potrzebny, ale skoro jak już pisałem wcześniej udało mi się to wygrzebać to publikuję. Jak odnajdę źródła "Code3 Tape Copy" (mam nadzieję że przetrwały) to też je opublikuję.

Aby wykorzystać ten loader należy go po prostu umieścić przed programem w formacie binarnym DOS-u. Jeżeli wczytywany program posiada segmenty INIT wato pamiętać o tym że po segmentach INIT w niektórych przypadkach będzie potrzebna dłuższa przerwa między rekordami. "Code3 Tape Copy" wykrywał te rekordy w których występują segmenty INIT i generował dodatkowe przerwy w odpowiednich momentach.

Dziś można skorzystać z Turgen-a ody Baktraaa i tam wszystko dzieje się z automatu (odpowiedni loader też jest dodawany). Więc stosowanie tego loadera nie wydaje się takie łatwe i oczywiste jak w przypadku gotowych narzędzi, no ale niech już to zostanie skoro była okazja aby to zaprezentować ;D

457

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

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

458

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

To jest KSO Turbo 2000. Bardziej rozbudowy opis na stronie JER-a w dziale serwis: Turbo KSO

NetSerwer napisał/a:

Czy potrzebny jest do tego cart z softem?

Przydałby się ze względu na wygodę, jeżeli nie masz to można się bawić we wczytanie KSO z kasety w trybie standard.

NetSerwer napisał/a:

Jak to było w magnetofonach z Turbo: jak się kabelka pod interface joy'a nie podłączy, to czy można zwykłe kasety wczytywać, czy po przeróbce to już tylko z Turbo?

Czy to z podłączonym czy bez podłączonego kabelka możesz wczytywać zwykłe programy w standardzie. Interface Turbo będzie działał dopiero wtedy gdy będzie aktywowany przez oprogramowanie.

459

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

Hej!

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

http://seban.pigwa.net/atari/Turbo_2600_from_Thomy/scr/T2600_fsk_spectrum.png

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.

Hrw napisał/a:

T2000F też miał długie bloki ale tam chyba nie dawało tak po uszach.

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.

tOri napisał/a:

Boszzzz ale to daje "po uszach" i "po głowie". Jak dawałem rade to wytrzymywać kiedyś?

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 ;-)

460

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

Dzień Dobry!

Zapraszam na kolejną sesję straszenia nietoperzy.... tfu... to znaczy na kolejny przykład systemu Turbo 2600 w działaniu.

Tym razem postanowiłem zaprezentować ciekawą właściwość systemu Turbo 2600, który jest zaprojektowany tak aby udawał że go właściwie nie ma :) tzn. siedzi sobie cichutko schowany "pod systemem operacyjnym", a jego działanie ujawnia się dopiero gdy rozpoczyna się transmisja z magnetofonem. Dzięki takiemu zachowaniu gry czy programy które nie wykorzystują pamięci pod OS-ROM, mają szansę nie zauważyć (jeżeli za dobrze nie sprawdzają) że coś się w systemie zmieniło... dzięki temu różne niestandardowe programy ładujące mogą działać tak jak wcześniej i będą myślały ze ładują ze standardowego urządzenia "C:", a tymczasem system Turbo 2600 potrafi podrzucić swoje procedury obsługi transmisji i dzięki temu nawet jeżeli nie da się wykorzystać tzw. formatu DB (długich bloków) to da się ładować standardowe rekordy, tyle że zapisane z prędkością do 2600 bitów na sekundę.

Zatem załóżcie słuchawki, schowajcie domowe zwierzęta tak aby nie musiały tego słuchać i zapraszam na pranie mózgu przy pomocy modulacji FSK o prędkości 2600 bps:

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

Jak widać na początku jest ładowany system Turbo 2600, który to ładuje boot-loader gry WARHAWK (zapisany w oryginale w formacie BOOT), a potem loader startuje i ładuje sobie poszczególne bloki danych z urządzenia "C:", jednak działający w tle system turbo 2600, podmienia procedury transmisji z magnetofonu w taki sposób aby było możliwe ładowanie z prędkością 2600 bps.

Czas ładowania tak zapisanej gry to 3 min 53 sek, podczas gdy czas ładowania w standardzie tej gry to 10 min 34 sek.

461

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

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.

462

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

Dzięki za zdjęcia! Te instrukcje które załączyłeś są po pierwsze fajnym kawałkiem historii, po drugie pozwoliły rozwiać moje domysły dotyczące tych programów. Tak czytając te instrukcje odnoszę wrażenie że część istotnych rzeczy nie została w nich napisana, tzn. albo twórcy systemu niektóre z aspektów użytkowania ich systemu uważali za oczywiste i nie pisali o nich, albo nie chcieli wchodzić w szczegóły techniczne, przez co koniec końców użytkownik był pozostawiany w sferze domysłów.

Pamiętam że podczas emisji niektórych odcinków Radiokomputera w których gościł człowiek opowiadający o systemie Turbo 2600, część informacji była przekazana w bardziej szczegółowy sposób, jednak kto by to po tylu latach pamiętał. Wychodzi na to że ten system po tylu latach odkrywam na nowo ;)

Thomy napisał/a:

//Znalazłem odręcznie pisane instrukcje do chyba wszystkich programów z kasetki T2600, postaram się to wszystko poskanować na dniach.

Super! Czekamy z niecierpliwością! :) Takie notatki z przeszłości mają naprawdę fajną wartość historyczną, a w dodatku niosą wiedzę zapomnianą już i przedstawiają ówczesny świat postrzegany oczami autora notatek!

463

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

@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.

464

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

Hejka!

Cała ta robota którą udało się wykonać to tak naprawę dzięki Tobie, bo zechciałeś podesłać "pacjanta" do analizy, robota robotą... ale zapewniam Cię że takie grzebanie się w przeszłości i odkrywanie koła na nowo, to dla mnie bardzo duża radocha. Dla niektórych to pewnie "oczywiste oczywistości", jednak dla mnie możliwość analizy i archiwizacji tego typu "perełek" to naprawdę fajne zajęcie. Najgorsze jest to że nie mogę temu poświęcić tyle czasu ile bym chciał, ale jak to się mówi powoli do przodu! Jeszcze raz WIELKIE dzięki za wypożyczenie interfejsu. Jak zakończę robotę i będę jej pewny w 100% to oczywiście będę się odzywał aby odesłać Ci powierzony sprzęt i kasety.

A jeżeli chodzi o materiały dotyczące T2600, to jak możesz to fotografuj wszystko co z tym systemem związane, nawet odręczne zapiski, bo to jest kawał historii warty zachowania. A tak na szybko to jakbyś rzucił okiem czy nie ma czegoś dotyczącego "współpracy" T2600 ze stacją dysków... nie bardzo wiem jak ten program zmusić co pracy ;-)

465

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

darpajdp napisał/a:

Co dotyczy zasilania to układ potrzebuje napięć +/-5V.

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.

466

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

No ja też kiedyś miałem taki pomysł bo byłem ciekawy jak on się by sprawdzał w porównaniu z tym co udało mi się kupić na giełdzie na grzybowskiej (klasyk oparty na LM324 i filtrach pasmowych), ale początkowo odstraszyło mnie symetryczne zasilanie tegoż układu (+/- 12V) ... a potem niedostępność NE565.

467

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

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).

468

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

darpajdp napisał/a:

Wczytywałem nim programy z Radiokomputera ale czy wszystkie były nadawane w T2600 czy 1300.

Z tego co pamiętam do w Radiokomputerze nie leciało nic w prędkości większej niż 800bodów, owszem leciały programy w formacie "Długich Bloków" sytemu Turbo 2600, ale nadawane z prędkością 800 bodów maksymalnie. Oczywiście nie słuchałem wszystkich audycji, bo czasami nie mogłem być fizycznie przy radiu w czasie emisji programu, ale chyba* nie zdarzyło się aby transmitowali coś szybciej niż 800 bodów.

*) piszę chyba, bo ludzka pamięć zawodna jest i być może były jakieś wyjątki, których nie zarejestrowałem.

darpajdp napisał/a:

Postanowiłem zmontować ponownie ten interfejs, kończę montaż i będą testy.

Z niecierpliwością czekam również na Twój raport z testów! Jedyny interface na NE565 jaki widziałem to konstrukcja przedstawiona w Mikroklan nr 1 z 1987 roku na stronie 35.

darpajdp napisał/a:

Przydał by się kopier ze stacji dysków na T2600.

Jeżeli nie uda się ustalić co robi i jak działa "Program do współpracy SYSTEMU TURBO 2600 ze stacja dysków" to będzie trzeba napisać własne narzędzie ;)

469

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

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 ;-)

470

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

Co prawda mam ze starych zapasów BC148, BC149B i BC159B ... ale poszedłem dokładnie tą samą ścieżką i do stworzenia testowej repliki interfejsu użyję BC549B i BC559B.

471

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

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.

472

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

Dobry Wieczór!

Mam chyba dobrą wiadomość... większość prac nad schematem została zakończona... udało mi się rozrysować i sprawdzić poprawność schematu i działania płytki PF1, zawierającej zespół aktywnych filtrów wejściowych interfejsu Turbo 2600, to ten element konstrukcji którego obecność zawsze podkreślali autorzy tego rozwiązania.

A cóż to za filtry? Po mozolnej analizie schematu połączeń na płytce oznaczonej PF1 (płytka filtrów wersja 1?) okazało się że na płytce znajduje się wtórnik emiterowy jak bufor wejściowy, a tuż za nim znajduje się dwu-sekcyjny komplet filtrów górno i dolno przepustowych drugiego stopnia, wszystko to wygląda tak:

http://seban.pigwa.net/atari/Turbo_2600_from_Thomy/sch/t2600_fsk_preamp_&_filter%20(preview).png
^^^ otwórz obraz w nowej karcie aby uzyskać większą rozdzielczość ^^^

Analiza topologii filtrów i wartości zastosowanych elementów pozwoliła wyznaczyć ich częstotliwości graniczne, dla filtra górno-przepustowego jest to  częstotliwość 2950Hz, filtr zatem w teorii nie powinien przepuścić sygnałów o częstotliwości niższej niż owe 2950Hz. Drugi z filtrów, tzn. filtr dolno-przepustowy ma częstotliwość graniczną wyznaczoną na 6680Hz, czyli w teorii z filtra nie powinno wydostać się nic powyżej 6680Hz. A jak jest w praktyce? Stromość zboczy filtra drugiego stopnia nie jest jakaś powalająca, dlatego konstruktor interfejsu postanowił zastosować drugą sekcję takich samych filtrów, aby uzyskać lepszą tłumienność filtrów oraz większą stromość zboczy filtrów połączonych kaskadowo.

Oczywiście teoria teorią, ale nie mogłem się powstrzymać przez praktycznym sprawdzeniem działania tego filtra i wyznaczeniu ich realnej charakterystyki, na początku chciałem to zadanie wykonać ręcznie, wyznaczając sobie kilka częstotliwości testowych i dokonując pomiarów poziomy sygnału na wyjściu... jednak zwyciężyło lenistwo i postanowiłem zautomatyzować proces. Wyniki pomiarów można zaobserwować na poniższym obrazku:

http://seban.pigwa.net/atari/Turbo_2600_from_Thomy/sch/t2600_filter_charateristics.png

Powyższy rysunek należy traktować mocno orientacyjnie, nie zachowałem odpowiednich warunków testowych... bo pomiarów dokonywałem w środowisku w którym dookoła była masa innego sprzętu wpływającego na wyniki pomiarów (masa zakłóceń, plątanina kabli).

Teraz czas na praktyczne testy interfejsu i zbudowanie repliki, tak aby mieć pewność że nie popełniłem błędów na schemacie, chociaż symulacje wskazują na to iż wszystko jest OK, chciałbym jeszcze wykonać taki interfejs, nawet w postaci pająka na tzw. płytce stykowej (breadboard).

Może ktoś z was dysponuje jakimś katalogiem tranzystorów w którym byłoby coś więcej napisane o BC206B? Nie wzgardziłbym jakąś notą katalogową, ew. podpowiedzią kto produkował te tranzystory w tamtych czasach? (SGS Thompson?)

A jeżeli chodzi o interfejs to pozostało jeszcze doprowadzenie schematu do porządku i publikacja już wersji finalnej. Ale to jeszcze chwilę potrwa.

EDIT: zapomniałem jeszcze dorzucić zdjęcia płytki filtrów PF1:

góra:
http://seban.pigwa.net/atari/Turbo_2600_from_Thomy/photos/T2600_SZOK_08_FILTER_PCB_TOP.jpg

dół:
http://seban.pigwa.net/atari/Turbo_2600_from_Thomy/photos/T2600_SZOK_08_FILTER_PCB_BOT.jpg

ps) skoro na płytce demodulatora FSK napisano PK2, ciekawe czy to oznacza że to druga wersja/generacja płytki czy też po prostu oznaczenie że to druga płytka wchodząca w skład interfejsu.

473

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

Hej!

darpajdp napisał/a:

Chyba znalazłem jedną nieścisłość w opisie wejścia zasilania jest "SIO_+5V_[12]". Jak dobrze rozumiem "[12]" na końcu to nr pinu złącza SIO Atari. Jeśli tak to powinno być 8 lub 10.

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.

474

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

raport z postępu prac ciąg dalszy...

przerysowałem układ formowania impulsów i cześć układu zasilania znajdującego się na górnej płytce wraz z demodulatorem FSK...

http://seban.pigwa.net/atari/Turbo_2600_from_Thomy/sch/t2600_fsk_pulse_shaper%20(preview).png
^^^ otwórz w "nowej karcie" aby uzyskać większą rozdzielczość obrazka ^^^

Skoro udało się zakończyć "zabawę" z górną płytką, to powoli zabieram się powoli do analizowania dolnej płytki przedwzmacniacza wraz z układem filtrów.

tOri napisał/a:

Szacunek się należy zawsze! Przy takim projekcie zawsze trzeba było do każdej sztuki podejść indywidualnie.

No dokładnie, ale to już raczej rzemiosło i pasja niż zwykłe "wyrobnictwo". I masz rację "SZOK" kompletny ;-)

475

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

darpajdp napisał/a:

BC206B to nisko szumny tranzystor którego polskim odpowiednikiem  w owym czasie powinien być tranzystor BC159B

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!