Wydaje mi się iż w ogóle nie potrzebnie martwisz się o bit-rate przy zapisie, o to dba kontroler. Jeżeli wydajesz mu komendę typu II (np. read sector lub write sector) to prędkość danych jakie do niego piszesz jest uzależniona od niego samego, jeżeli jest gotowy do przyjęcia następnego bajtu to sygnalizuje to używając lini DRQ (data request). Zresztą jest to napisane w dokumentacji:

Łącząc to z flow-chartem Type II Command, moża domniemać iż kontroler sam wie kiedy potrzebuje następnego bajtu bo poprzedni właśnie został zapisany i wypchnięty na wyjście w postaci szeregowej z użyciem odpowiedniego kodowania w zależności od gęstości i typu napędu z którym pracuje (FM, MFM).

Przyznaje iż ja osobiście nigdy nie miałem okazji programować żadnego kontrolera stacji dyskietek, a to co napisałem powyżej jest tylko moim domysłem zdobytym po przeczytaniu kilku datasheet-ów do różnych kontrolerów FDC. Także to co napisałem nie musi być do końca słuszne, jeżeli gdzieś nakłamałem proszę o sprostowanie :)

Co do zrobienia stacji na wspomnianych kontrolerach to nie wiem czy ktoś miał taką potrzebę i takie doświadczenie wcześniej, na pewno jednak kilka osób programowało te kontrolery, np. pisząc nowy/alternatywny firmware do stacji Karin Maxi. I to będzie chyba dobry przykład do analizy, na stronie Jer-a masz zarówno schemat stacji jak i zawartość ROM-u do niej.

schemat jest tu, a zawartość ROM-u tutaj.

Stacja Karin Maxi Drive to właściwie kontroler WD1772 wpięty w szynę PBI (Cart+Expansion port) i jest widziana przez system operacyjny ATARI jako tzw. nowe urządzenie (NEW DEVICE). Cały kod obsługujący kontroler jest zaszyty w romie i wykonuje go procesor ATARI (stacja nie ma żadnego innego mikro-kontrolera ani mikroprocesora). Analiza ROM-u tejże stacji pozwoli pewnie na rozwiązanie wszelakich wątpliwości.

Stacja KARIN-MAXI była bardzo fajnym rozwiązaniem. Była ultra szybka (podłączona pod szynę równoległą nie szeregową), jednak miała pewną wadę... była rozwiązaniem mało standardowym w tamtych czasach i część oprogramowania nie była z nią zgodna. Do tego aby umożliwić transmisję na sensownym poziomie, należało wyłączyć DMA ANTICA (wyłączony ekran przy operacjach I/O). Stacja była idealna do pracy, gdzie wymagało się szybkości (kopiowanie, programowanie [kompilacja]). Jednak część softu która miała zaszyta własne procedury I/O (tylko obsługujące SIO) po prostu na tej stacji nie działała.

A i jeszcze jedno... 0xF napisał DOS-a dla Karin Maxi Drive, udostępnił oczywiście źródła, które leżą na stronie ze źródłami Stryker-a, czyli tutaj , i z tego co pamiętam Fox wspominał iż jego MasterDos zawiera własne procedury obsługi WD1772 (Foxie popraw mnie jeżeli kłamię ;P)

UPDATE #1:

I jeszcze trochę obok tematu, pewnie Mikey zna już te linki... ale myślę iż warto je przytoczyć, oba rozwiązania trochę mało popularne chyba u nas ale dość ciekawe ze względu na sposób działania :) Mianowicie chodzi o emulatory napędów dyskietek, emulacja jest jednak na zupełnie innym poziomie :) Emulujemy bowiem sam napęd FDD. Idea projektów była taka aby zastąpić sam napęd FDD elektroniką która udawałaby napęd.

W sieci są obecnie rozwijane projekty dwóch osób: HxC Floppy Emulator oraz Sdisk Emul.

Dlaczego o tym piszę? Ano dlatego iż oba z projektów emulują napęd FDD na poziomie elektrycznym, więc zawierają kod dokonujący konwersji strumienia danych pobranych z danego obrazu dyskietki na strumień zakodowany kodem MFM. Być może byłoby to pomocne  w realizacji software-owego dekodera FM/MFM nad którym pracuje Mikey :). Projekt HxC ma dwie wersje, CPLD oraz bazującą na mikro-kontrolerze PIC serii 18Fxxx... Dodatkowo projekt Sdisk Emul emuluje szeregową stację dysków (SIO) małego Atari... w dodatku ma zaimplementowane proste OSD :) Schematy, źródła, firmware oraz PCB są dostępne na stronach projektów.

Projekt HxC jest dostępny w dwóch odmianach CPLD+USB (obrazy ładowane z poziomu softu na PC) oraz tzw. stand-alone czyli PIC+ karta SD na której są trzymane obrazy dysków.

UPDATE #2:

podstawowe info o FM, MFM i GCR jest tutaj: The floppy user guide

pozdrawiam
Seban

o to jak urat bym się nie bał... przy obecnej wydajności "ogólnie dostępnych" RISC-ów... (np. wspomnianego wcześniej AVR-a) i peryferiów w nich zaszytych (Rozbudowane timery, bloki CCP/PWM), nie będzie chyba problemu aby dokonać softwarowej obróbki danych (np. kodowanie i dekodowanie FM/MFM plus jakieś tam CRC).

I nie ma co ględzić Mikey-owi... ja tam wierzę że mu się uda ;)

Mikey: Jakby coś miało pomóc to gość od projektu Suska (http://www.experiment-s.de) zaimplementował kontroler WD1772 w VHDL-u... można podejrzeć jakby były jakieś wątpliwości.

Link chyba do ostatniej wersji źródełek VHDL-owych: http://download.experiment-s.de/Suska-I … l/vhdl.zip (katalog \vhdl\WF_FDC1772_IP\). Kiedyś nie był pełny bo nie wspierał modulacji FM (tylko MFM). Nie sprawdzałem czy się coś zmieniło od tego czasu kiedy tam zaglądałem.

update: niby teraz pisze: progress: Floppy-Controller      100%             WDC1772

tak nieco poza tematem jako ciekawostkę o architekturze 8051... Epi ma częściowo rację :) 8051 nawet ich twórca czyli Intel przestał to produkować już kawałek czasu temu... jednak jest jeden problem... pozostało sporo ludzi którzy doskonale znają ten mikrokontroler i lata przyzwyczajeń robią swoje. Do tego kilka firm podchwyciło to i postanowiło kontynuować produkcję serii zgodnych z 8051... są nawet takie co robią 8051 chodzące na 100MHz. Do tego taki core 8051 jest mocno zoptymalizowany i czasy wykonania większości instrukcji to 1 cykl. Przykładem firmy która uparcie tłucze 100-mipsowe rdzenie 8051 może być silicon-labs:

https://www.silabs.com/Support%20Docume … 2x-13x.pdf

i takie rozwiązania mają swoją grupę zwolenników :D Można powiedzieć iż mimo swej archaiczności i skazany na wyginięcie '51 wciąż żyje ;)

Mikey, dzięki za info! dotyczące kontrolera, tyle mi starczy :)  A jak z gęstościami Single/Enchanced? Będą wspierane?

również jestem zainteresowany! :)

pozdrawiam
Seban

problemem może być inne ustawienie skosu głowicy w twojej "wieży" i w twoim magnetofonie z AST. Spróbuj nowego MP3 jeżeli jeszcze nie próbowałeś.

UPDATE #1:

Wyciąłem te loadery z obrazu carta, są o wiele krótsze niż cały obraz carta, download poniżej:

1) loader AST_LOAD: format mp3, format cas i format boot
2) loader AST_BUT: format mp3, format cas i format boot
3) loader AST_BOT: format mp3, format cas i format boot

to tak na szybko, za czas jakiś dodam wszystko co było w carcie.

UPDATE #2: (dla zainteresowanych tematem)

4) handler AST-BASIC: format xex
5) program AST-COPY: format xex
6) program WYK_TO_AST: format boot i format cas
7) program UNICHANGER: format xex

pozdrawiam
Seban

Jak już ci się uda uruchomić klawisze START, SELECT i OPTION to wczytywanie wygląda tak:

Wciskasz OPTION + START potem włączasz komputer, słyszysz takie "beep", wciskasz PLAY w magnetofonie, następnie gdy wciśniesz RETURN silnik magnetofonu powinien zacząć się obracać. Taśma powinna być ustawiona na początku tonu pilota (takiego pisku). Po chwili gdy pisk się skończy powinieneś usłyszeć takie rytmiczne beep, ton pilotujący, beep, ton pilotujący... itd. do wczytania się całości.

Co do nagrania na wierzy nie wiem jak ci nagrało na kasetę gdy wieża dostała mono MP3 do nagrania. Jeżeli nagrała na obu kanałach to samo to powinno być OK, jeżeli nagrała tylko na lewym to nic się nie wczyta. Jak odtwarzasz tą kasetę na wierzy to piski słyszysz z obu głośników?

magnetofon na którym nagrywałeś jest mono czy stereo? Pytam dlatego iż atari czyta dane z kanału prawego a plik mp3 jest mono więc jeżeli się nagrało na lewym tylko to będzie tak iż magnetofon Atari nic nie odczyta. Dane muszą być nagrane na prawym.  Na lewym kanale może być nagrane cokolwiek... nawet muzyka którą będzie słychać podczas wczytywania ;)

Ok, no więc tak:

MP3 do nagrania na kasetę masz tutaj. Trochę to będzie powolne i traumatyczne, ponieważ wczytanie każdej gry będziesz musiał poprzedzić wczytaniem tego pliku w standardzie (trwało będzie to około 3 minut). To najprostsze rozwiązanie. Wczytujesz to z kastety włączając ATARI z przyciśniętymi klawiszami OPTION i START.

Szybszym rozwiązaniem byłoby nagranie samych loaderów, a nie całej zawartości cartridge. Ja niestety samych loaderów do AST nie posiadam, a czasu na wygrzebywanie ich z obrazu cartridge nie miałem za bardzo. Drugim rozwiązaniem stosowanym w starych czasach było nagranie mini-loadera (1-2 rekordy) w standardzie i reszty danych (np. pełnego systemu już w turbo). Jeżeli ktoś ma ochotę i czas na przygotowanie takiego wynalazku to proszę:

"zdumpowany" cart AST w formacie DOS ast_cart.xex (można uruchomić z dowolnego DOS-a)
"zdumpowany" cart AST w formacie BOOT ast_cart.bot (można uruchomić po nagraniu na kasetę jako tzw. boot, wciskamy OPTION+START, włączamy ATARI i wczytujemy)

A może ktoś ma jakieś narzędzia i loadery do AST? Jeden z mikro-loaderów kiedyś dostarczył Pecuś, jednak nie mam nic co by nagrywało coś w AST (np. z pod DOS-a, dodając odpowiedni loader).

I jak się komuś jeszcze przyda to proszę, tutaj wersja CAS z której stworzony został plik audio: ast_cart.cas

A i jeszcze jedno, tutaj link do wątku w którym Pecuś udostępnił swój loader: http://atariarea.krap.pl/forum/viewtopi … 162#p76162

Ponieważ loaderów do AST było kilka rodzajów nie wiem jakiego rodzaju format wczytuje ten udostępniony przez Pecusia (nigdy nie miałem AST, dopiero niedawno zacząłem nadrabiać zaległości ;] )

pozdrawiam
Seban

http://www.faqs.org/faqs/atari-8-bit/fa … on-89.html

no źle sie wyraziłem trochę... pisząc software-owy interlace miałem na myśli typowe wyświetlanie na przemian linii parzystych i nieparzystych obrazka, czyli wszystkie TIP-y, HIP-y, RIP-y, XLP-MAX. To co dawało nam normalnie zwiększenie liczby kolorów/odcieni. Czyli dwie DL przełączane co ramkę, i linie parzyste i nieparzyste obrazka wyświetlane na przemian w tym samym miejscu.

No właśnie cała zabawa w tym iż możesz poinformować monitor/TV który aktualnie półobraz leci. Typ półobrazu (parzysty lub nieparzysty) monitor czy TV określa sobie na podstawie imp. synchronizacji pionowej w którym znajdują się informacje o typie aktualnie nadawanego półorazu.

Wydaje mi się iż czasach projektowania TIA,CTIA,GTIA czy nawet VIC-a... nikt nie myślał o wyświetlaniu obrazu z przeplotem, ba nawet Shifter z ATARI ST fabrycznie nie potrafi wyświetlać obrazu z przeplotem... pierwsze fabryczne prawdziwe tryby interlace miała chyba dopiero AMIGA.

Przy wyświetlaniu obrazu z przeplotem obrazów statycznych nie uzyskujemy żadnych efektów ubocznych, jednak gdy zaczyna się ruch (w szczególności w poziomie)... no to zaczynają się problemy.