Z "jeżdżeniem walcem" oczywiście żartowałem... posiedzę oczywiście nad tym bo teraz to już mi spokoju nie da :) No i to jest dokładnie ten z porysowanym logo... co do działania poprawnie "wtedy", to mogło tak być że nie było tak jak pisałem tylu źródeł zakłóceń w eterze jak dziś... przejrzę obwody wejściowe może coś jest usunięte, ew. wymienione ... ale powodów tych wszystkim zmian nie rozumiem, nie mają one najmniejszego sensu... patrząc na to wręcz bym powiedział że wprowadzone zmiany zmniejszają odporność magnetofonu na zakłócenia :)

Zacieranie oznaczeń jestem w stanie zrozumieć w autorskich rozwiązaniach :) jednak zacieranie oznaczeń w klonowanych rozwiązaniach? :) No dobra... może to coś utrudniało w przypadku mniej obeznanych z elektroniką osób, jednak ścieranie oznaczeń z rezystorów i to w taki sposób że uszkodzono ich powłokę albo próba zatarcia pasków rezystora tylko od góry... wydaja się wręcz komiczna :D ja rozumiem że starcie trochę warstwy węglowej zmienia oporność rezystora... jednak nie to było zamysłem autora w tym wypadku :) Poza tym rezystor czy kondensator, nawet w tamtych czasach bardzo łatwo było zmierzyć :)

A z ciekawości jakiego softu czy carta używałeś do obsługi turbo w swoim magnetofonie? ew. czy to turbo miało jakąś nazwę?

Hello!

Tym razem na warsztacie mocno sfatygowany XC11, magnet w stanie dość opłakanym, "przytopiony" spód obudowy, w środku system Turbo, i straszna plątanina przewodów, widać że po zamontowaniu systemu turbo dobrał się do niego ktoś i postanowił wykonać kilka modyfikacji, dołożył wyłącznik odcinający linię DATA_IN, od komputera, wypiłował drugą dziurę w obudowie i dodał sobie drugi LED sygnalizujący zapis, PCB zmodyfikowane w sekcji zasilania silnika. Ktoś chciał dołożyć sobie trochę filtrów, niestety modyfikacje spowodowały że zasilanie silnika zamiast 5V, spadło do 4V, przez co silnik nie miał zupełnie siły przy większym obciążeniu przez mechanizm magnetofonu. Do kompletu zniszczony i łatany kabel łączący komputer z magnetofonem, oczywiście standardowa usterka dotycząca  pękniętej masy zasilającej sekcję silnika.

Jeżeli chodzi o system turbo to już kiedyś miałem styczność z tą wersją systemu, a jest to klon czeskiego Turbo 2000 opracowanego przez Jiri Richtera. Klon do tego stopnia że nawet PCB skopiowano 1:1, pisałem o tym w tym poście: Atari HARD Turbo

Z biegiem czasu uświadomiłem sobie że Wrocławskie Turbo2000/3000 czy też "Auto Turbo" jak i zarówno Atari Hard Turbo (to rozwiązanie było montowane przez ludzi ze "studia komputerowego" w DT Wars, co widać w wątku o AHT,  a świadczą o tym etykiety kaset oraz napisy pokazujące się po wystartowaniu loadera do AHT) to wszystko to rozwiązania bazujące na czeskim Turbo 2000 pana Richtera.

Jeżeli chodzi o Auto Turbo, to co prawda nie mam nagrań pochodzących z tego systemu, a w wątku o Auto Turbo zrobił się straszny "offtopic", jednak wszystko wskazuje na to iż AutoTurbo było również popularne we Wrocławiu, i też było klonem czeskiego Turbo2000.

Niestety obrazki z wątku u Auto Turbo zniknęły, a ja nie robiłem ich kopii więc obecnie nie bardzo pamiętam co na nich było. Jednak dzięki uprzejmości i dobrym chęciom ludzi udało się odzyskać soft obsługujący wrocławskie rozwiązania Turbo. I tutaj możemy wrócić do naszego poczciwego XC11, który wiele przeszedł, zaprezentuje tutaj same płytki z elektroniką, bo reszta nie jest już jakaś wyjątkowo, zatem środek z płytkami (główną XC11 i płytką turbo) wygląda tak:

^^^ powyżej widać także przeróbki, czyli przełącznik odcinający DATA_IN, oraz dodatkowy LED sygnalizujący zapis (autor mod-ów wykorzystał nieużywaną sekcję przełącznika odczyt/zapis, aby sterować dodatkowym LED-em). Zdjęcie wykonałem już po poprawkach w okablowaniu bo owych dodatkowych kabli były jakieś bezsensowne "kilometry" upchane gdzie tylko się dało.

A tutaj zbliżenie na samo PCB z płytką turbo:

^^^ zdjęcia spodu nie robiłem, bo jest identyczne z tym co można znaleźć z opisie czeskiego Turbo 2000 (strona 23).

Cóż mi pozostało do zaprezentowania? chyba tylko schemat, oczywiście "zrysowany" z tego egzemplarza XC11. Nie muszę chyba mówić że schemat jest w 100% zgodny z czeskim T2000? ;-) W przypadku tej wersji interface dla XC11 różnią się nieco wartości niektórych elementów.

^^^ Po otwarciu obrazka w nowej zakładce będzie on zaprezentowany w wyższej rozdzielczości. Dla zainteresowanych również wersja wektorowa (PDF): T2000_T3000, AHT, AT (XC11 ver).

Jedyna modyfikacja w torze zapisu XC11 polega na wymianie rezystora (R124) z 10kΩ na 4.7kΩ, dokładnie tak samo jak w przypadku czeskiego Turbo 2000.

Co mogę jeszcze napisać? Otóż nagrałem kasetę z programami z wątku Atari Hard Turbo, wszystko działało bez problemu. Używając również SIO2PC oraz programów Tomasza Rolewskiego (np. Special Copy, Corwin from Amber) nagrałem sobie parę gier zarówno w systemie Turbo2000 oraz Turbo3000, wszystko działało bez problemu, zapis i odczyt przebiegał  bez żadnych problemów.

Jeżeli ktoś ma jakieś kasety nagrane w Auto Turbo i mógłby się podzielić ich "zrzutami", to można by zweryfikować czy na 100% ten system będzie zgodny z tym interface, jestem na 99% pewny że tak, ale zawsze można sprawdzić zgodność formatu danych.

No i jeszcze ostatnie słowo, ogromne podziękowania należą się dla tEDDYbOAR oraz VOY-a za to że zgrali udostępnili oprogramowanie dla wrocławskiego Turbo2000/3000 oraz innych ciekawych programów Tomasza Rolewskiego czy Bartka Selingera.

Jeżeli ktoś chce lub może się podzielić informacjami lub ciekawostkami dotyczącymi wrocławskiego Turbo2000/3000, AutoTurbo lub oprogramowania obsługującego te systemy, bardzo chętnie posłucham.

Oczywiście duża część moich opisów to czyste domysły (poparte dostępnymi dla mnie materiałami) jednak nie obawiajcie się korygować i poprawiać mnie gdybym mylił się lub moje domysły były błędne.

Hej!

Z wielką chęcią przygarnę.

czy w pełni sprawny tego jeszcze go końca nie można na 100% powiedzieć, aby mieć 100% pewności uruchom test GTIA z SysInfo: http://drac030.krap.pl/pl-si-pliki.php

więcej info o możliwych wadach GTIA, tutaj: http://atariki.krap.pl/index.php/GTIA

wątek chyba dobry, s system już widziałem bo wcześniej Voy wklejał w tym wątku informację o nim... ale nie miałem jeszcze czasu się temu przyjrzeć, bo czeka jeszcze trochę sprzętów od uicr0Bee-ego w kolejce.

Posty Voy-a w których wrzucił informację o "Injektor" i jeszcze innych systemach:

http://www.atari.org.pl/forum/viewtopic … 60#p263060

http://www.atari.org.pl/forum/viewtopic … 67#p263067

Z ciekawości jak się już uporam z bieżącą kolejką to rozrysuję schemat tego "Injektora", wygląda na odmienne rozwiązanie od tych które do tej pory widziałem.

EDIT#1:
Zastanawia mnie natomiast jedna sprawa, na screen-shocie ze strony opisującej Injektora-a...

Widać jakiś program pod którym podpisał się "Michal Galinski", ktoś zna ten software? Wygląda na jakiś program kopiujący, ale nigdy wcześniej go nie widziałem. W dodatku wgląda jakby to był zwykły program kopiujący dysk <--> kaseta obsługujący jedynie "standard".

EDIT#2:
Nie za wiele rozumiem po hiszpańsku, jednak z instrukcji wynika, że używając programu Michała Galińskiego podczas konwersji standard ---> turbo, zapisu w turbo dokonuje się wybierając jako urządzenie wyjściowe stację dysków. Nie wiem jak ów program działa, ale można zgadywać że w systemie pewnie jest instalowany handler "D:" obsługujący zapis w turbo.
W sumie instrukcja mówi o zupełnie innym programie niż ten kopier Michała Galinskiego który widać na screen-shotach. W sumie to nie wiem dlaczego na screenach jest ten kopier.

EDIT#3:

Z tego co rozumiem z wątku na forum dotyczącym inż. wstecznej "Injektora", kaseta z programem kopiującym nie była czytelna, udało się odzyskać tylko jakiś program do konwersji w BASIC-u. Właściwy kopier/konwerter przepadł. Plików WAV o których mowa wątku już chyba nie ma nigdzie w sieci. Niby w późniejszych postach ludzie piszą że udało im się pobrać WAV i nagrywając go na kasetę kilka razy nawet udało im wczytać ten soft, jednak żadne linki które są załączone w postach już nie działają, a wayback-machine nie archiwizowało tych niszowych rzeczy :D

Ślepota nie boli, Voy zapodał link do bloga, gdzie jest spora część softu dla tego systemu: https://dogdarka8.blogspot.com/search/label/COPIADORES. Niestety nadal nie mogę namierzyć tego kopiera od "Michal Galinski".

EDIT#4:

Wszystko wskazuje na to że ten "Injektor" to turbo oparte o klasyczną modulacje FSK z tym że dekoder FSK montowany dodatkowo do magnetofonu jest w stanie dekodować o wiele większe bit-rate, jeżeli dobrze patrzę w źródła to chyba domyślną prędkością transmisji jest około 4000 bps, do tego przerwy IRG zostały skrócone. Co prawda to bardzo wstępna analiza, ale wychodzi na to że to taki "odpowiednik" Turbo 2600 ... tyle że teoretycznie szybszy i software-owo o wiele mniej skomplikowany (kod loadera jak i programu kopiującego). Nie wiem które rozwiązanie było pierwsze, w kodzie źródłowym Injektor-a widnieje data 05.09.88... nie pamiętam kiedy było opublikowane Trubo 2600. Ja o nim po raz pierwszy usłyszałem w audycji radiowej Radiokomputer.

Hej!

Wysłałem e-mail (via forum) z informacjami jakich potrzebują aby wysłać paczkę.

Wiem że pytanie może się wydawać dziwne, ale jakiego zasilacza używasz? oryginalnego czy jakiegoś nowoczesnego impulsowego?

Pytam bo na obrazku "composite" widać takie jakby poziome równomierne pasy/zmiany jasności... wygląda trochę jakby Ci się robiła jakaś wredna pętla masy (tzw. ground loop), ale to może być kwestia grabbera lub peceta do którego masz podłączony grabber.

100% racji ;) Mój przykład był zbyt mało skomplikowany, nie uwzględniłem tego że faktycznie offsety do poszczególnych pól struktury można określić już na etapie kompilacji.

A już z czystej ciekawości, jak CC65 poradzi sobie jeżeli to będzie tablica wskaźników zawierająca adresy np. stringów?

#include <stdio.h>

#define _countof(array)    (sizeof(array) / sizeof(array[0]))

void main(void)
{
    char *msg[]={"ala ma kota", "atari rulez!", "undercover error?", "super bulgot 3000"};

    for(uint8_t i=0; i < _countof(msg); i++)
    {
        printf("%s\n",msg[i]);
    }
}

ps) wiem że mogę sam sprawdzić, jednak Ty masz to wszystko zapewne w głowie i znasz odpowiedź bez sprawdzania czegokolwiek ;)

Da się oczywiście i w ten sposób, ale stos jest po prostu za mały aby dało się nieco bardziej skomplikowane rzeczy w ten sposób zrealizować, nie wiem jak jest dokładnie w CC65 (trzeba by podpytać np. Fox-a) ale wydaje mi się że stos jest emulowany (przynajmniej gdy wybierzemy "większy model pamięci/adresowania"). Niestety narzut kodu przy realizacji w tego w ten sposób jest dość spory i mam wrażenie że wydajność kodu generowanego przez kompilator drastycznie spada.

Kiedyś liczyłem na to że KickC ma szansę stać się całkiem fajnym kompilatorem, ale prawdę mówiąc przestałem śledzić zmiany i postępy w projekcie, bo miał on fazę kompletnego zastoju.

Z MadPascalem mam ten problem że to Pascal, to był co prawda jeden z pierwszych języków (po BASIC, ASM, etc.) których się uczyłem, ale gdy tylko przesiadłem się na C, to pisanie w Pascalu jakoś przestało być, hmmm... no nazwijmy to "atrakcyjne". Doceniam oczywiście starania TeBe i ogrom pracy który włożył w MadPascala, ogromny szacun za to! Ale sam Pascal jakoś mnie odrzuca, być może mam jakieś bezsensowne uprzedzenia i pewnie gdybym posiedział i przystosował się ponownie to by to jakoś poszło, ale ja po prostu robię za małe rzeczy aby wytaczać taką armatę jak MadPascal to moich prostych/prymitywnych projekcików... jestem jeszcze z tego pokolenia dla którego pisanie w pure ASM to czysta radocha :)

Ponieważ się "nie znam" to się wypowiem ;) Wydaja mi się że w przypadku 65xx i C problemem stają się również operacje które wymagają użycia dużej ilości wskaźników, przykładowo:

ctx->iocb.len = 256;

będą również kłopotliwe do prostej/optymalnej realizacji za pomocą "zasobów" które są dostępne w 65xx.

Do kompletu jakieś nie ma mowy o ramkach stosu, etc. Trzeba tak naprawdę emulować "duży" stos, jeżeli chcemy mieć możliwość operowania na większych strukturach danych, czy lokalnych zmiennych znajdujących się na stosie.

Te narzędzia jeszcze do nie tak dawna nie były darmowe... rzuciłem na nie okiem w momencie kiedy WDC udostępniło je, ale nie byłem zachwycony tym co wypluwał ten kompilator. Do tego instrukcja i sam kompilator i linker wydawały mi się strasznie toporne i chwilę mi zajęło zanim poprawnie udało się skompilować cokolwiek :)

Zresztą nie oszukujmy się... 6502 nie jest przyjaznym procesorem jeżeli chodzi o kompilatory, w większości przypadków tam gdzie ktoś wkłada 65xx pisanie w C mija się z celem, bo kod wygenerowany przez kompilator przy małym projekcie jest tak duży że tracimy połowę zasobów tylko dlatego że "kompilator".

Widziałem kiedyś też to co generuje komercyjny kompilator IAR-a, mimo że firma ma długą tradycję w pisaniu kompilatorów i ich kompilator robił co mógł, to kod nie był również zachwycający, niestety jak pisałem już wcześniej same ograniczenia architektury powodują że nie da się wygenerować sensownego kodu przy bardziej złożonych "konstrukcjach językowych". Może w przypadku 65816 jest lepiej, ale tutaj nie mogę się wypowiedzieć bo nie zajmowałem się analizą kodu wygenerowanego dla 65816 przez jakikolwiek kompilator.