Hej!

Tak z czystej ciekawości sprawdziłem czym się różnią pliki podesłane przez Mikera od wersji Kaz-a :)
A więc pierwsza wersja od Mikera która odpala się pod QMEG-iem to wersja BOOT (zapewne zgrana z kasety), którą QMEG potrafi wczytać bez problemu. Końcowa wersja od Mikera została potraktowana dokładnie tym samym programem co wersja KAZ-a (przerabiającym boot na file). Jednak w wersji od KAZ-a od offsetu $4EE3 zaczyna panować istna sieczka... wygląda mi to na błędne skopiowanie z kasety, ostatnie 6 bajtów śmieci które występują w wersji od KAZ-a to w wersji poprawnie zgranej ciąg bajtów $e0,$02,$e1,$02,$3f,$1f a wiec segment RUN wskazujący na adres $1f3f.

A tak poza tym to wygląda na kompilowany BASIC :)

pozdrawiam
Seban

Hej!

Tu nawet nie chodzi o to co się znajduje od adresu $1f00, plik binarny jest po prostu uszkodzony po pierwszym segmencie danych. Zawiera jakieś parę bajtów śmieci. Nie przyglądałem się temu dokładnie, ale wygląda na to iż jest to jakaś przeróbka file-a na program typu "BOOT" a potem ktoś próbował to z powrotem na wersję file przewalić :) Generalnie wychodzi na to iż adres pierwszego uruchomienia powinien być ustawiony na $1f3f. Ale nie wiem czy plik zawiera całość danych... masz oryginalną wersję boot?

Seban

Hej!

Jer bez niepotrzebnych nerwów... jak przeczytałem twojego posta to prawdę mówiąc myślałem że chodzi Ci o "dopalacze" mikroprocesora, coś w stylu Pasiowego F7, Warp4 czy Hyper Speed. Potem napisałeś ... "Pokey, N systemów, itd.". To raczej nie są "dopałki" w moim rozumieniu tego słowa. Wiec poniekąd X-ray miał rację.

ps) nie jestem żadnym naukowcem :)

pozdrawiam
Seban

Hej!

Pierwszy z nich to mod z cracktra do gry Vroom na amidze.
Drugi, nie bardzo pamiętam ale jest duże prawdopodobieństwo iż moduł właśnie tak się nazywał, czyli techno_florid.mod

pozdrawiam
Seban

Hej!

No ja właśnie o tym wiem... ale wiedzieć w teorii a zobaczyć z prawdziwego FGTIA to co innego :)
Ale sam mogę sobie za symulować robiąc AND #$0E z kolorem w GR.9 :)

pozdrawiam
Seban

Hej!

No nie do końca analogówka robi kolor niestety...  Kodowanie koloru następuje wewnątrz GITA... dekoder PAL bierze informacje o kolorze na podstawie różnicy faz pomiędzy impusem "brust" koloru a fazą wygenerowaną przez GTIA, całe powstawanie koloru powstaje poprzez zwiększenie różnicy tych faz... w praktyce polega to opóźnieniu sygnału podnośnej koloru względem generatora wytwarzającego sygnał "color brust", dość prosto jest to wyjaśnione np. tu:

http://www.atariarchives.org/cgp/Ch02_Sec07.php

tu nieco więcej torii dla wnikliwych:

http://web.archive.org/web/200605051232 ... notes.html

(kurcze trzeba by to gdzieś zgrać bo zginie niebawem pewnie :( )

niestety to wszystko jest wewnątrz GTIA, zmodulowany sygnał koloru GTIA wystawia na 21 pin (COLOR).

Informacja o jasności (luminancji) jest zamieniana na postać analogowa za pomocą prostego przetwornika C/A zrobionego z bramek i kilku  rezystorów.

Reasumując, informacje o przesunięciach fazowych (a co za tym idzie kolorze) są zaszyte wewnątrz GTIA i nie wpłyniemy na kolory jakie GTIA generuje :(

pozdrawiam
Seban

Hej!

Dzięki laoo za info... tyle że niestety ja nie jestem w stanie sobie skompilować tego z CVSa... po prostu nie potrafię :)

pozdrawiam
Seban

Hej!

Sikor... ale do tego upgrade-u wykorzystujesz tą samą gita którą masz w komputerze... nie musisz dokładać żadnej dodatkowej :)

Seban

hej!

http://pl.wikipedia.org/wiki/BCD

pozdrawiam
Seban

hej!

Ja używam... ale generalnie to wolę FAR-a i Total Commandera zainstalowałem tylko po to aby używać twojego plugin-a :)
Pomysł z wirtualnym system plików jest po prostu świetny! (mieć ATR-a podpiętego jako napęd w systemie to moje marzenie)
także trzymam kciuki! Plugin jest po prostu wygodny, byłoby super aby powstała finalna wersja!
A cudo które pozwoliło by podpiąć ATRa jako napęd w systemie byłoby powalającą możliwością :)

TeBe: dzięki za radę, działa wyśmienicie :D

pozdrawiam
Seban

Hej!

Powiem tak... z mojego doświadczenia wynika iż jakiekolwiek STA $D40A w trakcie transmisji SIO jest niedopuszczalne.

Zawsze może się ono trafić w nieodpowiednim momencie, takim w którym trzeba odebrać bajt z POKEY-a i wtedy kupa... mamy zapewniony over-run error na 100%. W prawdopodobieństwa niby wynika iż zdarzyć się to może niezwykle rzadko jednak w praktyce zdarza się dość często :( efekt jest taki iż cała transmisja przez SIO się przywiesza i musi zostać rozpoczęta od nowa, przez co tak naprawdę więcej jest ponowień transmisji niż poprawnych danych. także proponuje odpuścić sobie jakiekolwiek $d40a podczas wczytywania... DLI trzeba wykorzystać z bardzo dużą rozwagą, do tego DLI może zostać opóźnione przez IRQ które się aktualnie wykonuje. Także jeżeli się wykonuje jakiś DLI to nie można liczyć iż wykona się ona w tym miejscu w którym jest. Jedynym sensownym zastosowaniem DLI podczas transmisji jest zmiana kolorów i to trzeba to robić tak aby zostawić trochę pustych linii po wystąpieniu DLI, bo może ono zostać opóźnione tak jak mówiłem wcześniej przez aktualnie wykonywane IRQ. Do tego dochodzi różne zachowania różnych stacji w przypadku błędnych transmisji. Jakiekolwiek dopalenie szybkości SIO w przypadku DLI nie ma szans na powodzenie, zostaje tylko 19200bps. Co to napisałem wynika moich doświadczeń przy pisaniu loaderów do Bitter Reality i Overmind. Mam nadzieję iż nic nie pokręciłem, bo od tamtych dni już spoooooro czasu minęło :)

pozdrawiam
Seban